“A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution… “

– Satoshi Nakamoto

This is the very first sentence of the Bitcoin whitepaper.

When Bitcoin V0.1.0 was released in 2009, it contained a proof of concept feature that is perhaps the most overlooked in its history. It was called “IP transactions” and it demonstrated the type of peer interactions that is referenced in that sentence. When speaking about peers in a Bitcoin context, it is common to assume it is a reference to nodes. Nodes are in fact peers to each other. However, there is more than one type of peer in Bitcoin. We can see from the general definition of the word that a set of peers is defined by commonality.

This doesn’t preclude there being more than one set of peers. The peers referenced in the first sentence of the whitepaper are the users of the Bitcoin network, not the nodes. What use is the Bitcoin network without users, preferably billions of them?

The IP Transaction feature demonstrated exactly that direct user to user interaction which, when coupled with SPV (Simplified Payment Verification – referenced in section 8 of the Bitcoin whitepaper) light clients, is precisely what allows Bitcoin to scale. It is a very simple scaling principle: Don’t do work that isn’t relevant to you. It is SPV that allows users to ignore every part of the Bitcoin transaction history that isn’t relevant to them whilst still obtaining the security benefits of Bitcoin.

It was however a rudimentary implementation, a proof of concept if you will. And even Satoshi acknowledged that, in its original form, the IP Transactions implementation had some real problems:

• How peers will find each other
• Insecure connections
• NAT traversal
• Susceptibility to man-in-the-middle attacks

Additionally, it didn’t complete the picture as is common for prototypes. It didn’t have any facility for obtaining, verifying or passing on SPV merkle proofs.

Today, the BSV Infrastructure Team are releasing three beta products simultaneously that, along with several other services, provide all the tools required to reimplement the IP2IP vision and address all of these well known problems in the process. 

BSV v1.0.6 (release code name “Push”)

• New functions to provide and verify Merkle proofs
• ZeroMQ notifications on double spend detection
• (WIP) p2p broadcast of double spend detection to enable network wide awareness.

mAPI v1.2

• Push based callback notifications for merkle proofs and double spends

SPV Channels v1.0.0 

• An end to end encrypted messaging nano-service with push capability that provides an always on point of presence for a Bitcoin user and provides a unified interface for handling both online and offline messaging.
• As an always on service, it solves the NAT traversal problem by enabling any two parties to communicate in a private channel via a blind intermediary such that only outbound connections are required. This is similar in principle to how services like TeamViewer, Skype and Zoom work seamlessly even between users that are behind firewalls but with full e2e encryption.

SPV Channels is a new offering from the BSV Infrastructure Team. Think of Channels as something similar to an IMAP mail server. If you’re offline, it collects messages for you, but when you’re online it passes them straight through to you. If you and another party are both online the experience is similar to having a direct connection, but e2e encrypted by default and without any of the horrible mail header format requirements. It can integrate with Paymail but the server itself has no visibility of the content and is completely agnostic to it. Other than that, it’s not very Bitcoiny at all. But it does fill a critical gap in the workflow of a peer 2 peer Bitcoin interaction.

The uses of SPV Channels go beyond that – to almost any off-chain coordination problem in Bitcoin and even outside of Bitcoin, such as;

• Coordinating multisig or threshold signature groups
• Spend notifications for wallets
• Generic notification for anything
• A base layer for a new generation of self sovereign email and/or instant messaging.

A use case with mAPI

Early versions of mAPI (formerly known as Merchant API) solved a couple of key problems like fee discovery and direct-to-miner transaction submission. Getting responses from miners about acceptance is simple as it can come as a direct response to the submission request. But there are events that happen after that user-miner connection is closed, such as receiving an SPV proof when the transaction is mined into a block. We put in a rudimentary mechanism of getting updates by polling mAPI for transaction status. But this is inefficient and for a particular use case, learning about double spend attempts, it is time critical so a better mechanism was required. 

Enter the “push” model. Registering for a callback on an event is a common programming paradigm. SPV Channels enables this for user-miner interaction. When registering for a callback, you typically need to provide an always-on URL for the callback to go to. This isn’t something users on a mobile phone are likely to be able to provide. 

Enter SPV channels. A hosted service (or self-hosted if you like) that acts as a channel for the user to receive messages. If the user is online, they’ll receive the messages straight away. If they are offline, the messages will be stored and forwarded as soon as the user comes online. In fact, the first internal version of SPV Channels was unimaginatively named “Store and Forward”.

So the workflow goes something like this:

1. Customer and Merchant find each other via Paymail service discovery; and establish two way encrypted communications via SPV Channels.
2. Merchant finds a miner’s mAPI via MinerID.
3. Merchant requests a fee quote from miner via mAPI.
4. Merchant sends customer a transaction specification via BIP270 including the required fee, payment amount and any other requirements for the transaction.
5. Customer sends the transaction (possibly along with merkle proofs and other requested info) to the merchant.
6. Merchant submits the transaction to miner via mAPI and registers an SPV Channel URL for callbacks.
7. If a double spend is detected, the miner will send a message to the SPV Channel which the Merchant will receive immediately if online.
8. Once the transaction is mined into a block, the miner sends a merkle proof to the SPV Channel – which the merchant wallet can retrieve and store in its database.
9. Optionally, the merchant sends the merkle proof back to the customer via their SPV Channel.

Who pays for all these services?

In the early days, the costs of operating these services will likely be minimal so someone will probably offer them for free. But eventually, the cost of such hosted services will add up. Wallets, Miners and payment processors might absorb some of those costs as part of their service offering.

But there is another option. There are a number of new service offerings here, so it’s worth listing them:

1. Hosted Paymail
2. Hosted SPV Channels service (could be provided by paymail provider)
3. Merkle proof provision (not necessarily from the miner that mines the transaction)
4. Double spend notification (can be any or many miners monitoring for you)

It will be interesting to see how the BSV ecosystem develop and what kinds of businesses decide to offer these services.

Assume for some reason that you request each of the 4 services from 4 different service providers, all of them are services provided in the context of a transaction. This is a perfect use case for adding nano-payment outputs to a transaction. One or ten satoshis to each service provider for a one off service with no implied lock-in to each which creates a strong incentive for them to provide the service well.

The future of SPV Channels

The initial implementation of SPV Channels released today provides the basic framework and is currently only optimised for desktop. Our near term priorities are to get mobile client libraries available that leverage the push capabilities of iOS and Android devices. Further integrations with Paymail are required and, of course, we need horizontally scalable implementations. We can definitely see the provision of a combined channels/paymail hosted service being in high demand and look forward to seeing who is the first to offer it.

The future of SPV workflows

In what we have presented today, we have offered solutions to the blocking issues for the complete SPV workflow. Many of these solutions can be improved upon and optimised, but the end to end use case is possible right now with these components. We expect this entire workflow to be the subject of much discussion by the business operators on BSV and quite possibly changes or complete alternatives proposed and adopted. But for now we have a base, a starting point that developers of consumer targeted products can begin building upon right now.