“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:
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 Bitcoin SV 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.
Bitcoin SV v1.0.6 (release code name “Push”)
SPV Channels v1.0.0
SPV Channels is a new offering from the Bitcoin SV 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;
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:
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:
It will be interesting to see how the Bitcoin SV 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 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.
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 Bitcoin SV 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.