Satoshi Nakamoto’s peer-to-peer vision for Bitcoin

Steve Shadders has been working in the Bitcoin infrastructure since 2011. He brings his ecosystem-wide perspective to help build the mining and UX infrastructure required for Satoshi’s vision.
(Courtesy photo by Ed Pownall)

“A pure peer-to-peer version of electronic cash would make it possible to send online payments directly from one party to another without contacting 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 included a proof-of-concept feature that is possibly the most overlooked in its history. It was called “IP Transactions” and demonstrated the type of peer interactions referred to in this sentence. When you talk about peers in a Bitcoin context, it is often assumed that it is a reference to nodes. In fact, nodes are peers to one another. However, there is more than one type of peer in Bitcoin. We can see from the general definition of the word that a group of peers is defined by commonality.

This does not preclude there being more than one group of peers. The peers referred to in the first sentence of the white paper are the users of the Bitcoin network, not the nodes. What’s the use of the Bitcoin network without users, preferably billions of them?

The IP transaction function demonstrated exactly this direct user-to-user interaction, which in conjunction with SPV light clients (Simplified Payment Verification – see Section 8 of the Bitcoin whitepaper) enables Bitcoin to be scaled precisely. It’s a very simple scaling principle: don’t work that isn’t relevant to you. With SPV, users can ignore any part of the Bitcoin transaction history that is not relevant to them while still enjoying the security benefits of Bitcoin.

However, it was a rudimentary implementation, proof of concept if you will. And even Satoshi acknowledged that implementing IP transactions in their original form had some real problems:

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

In addition, the image has not been completed, as is common with prototypes. There was no way to obtain, verify, or share SPV Merkle evidence.

Today the Bitcoin SV Infrastructure Team is releasing three beta products simultaneously which, along with several other services, provide all of the tools needed to reimplement the IP2IP vision and fix all of these known issues.

Bitcoin SV v1.0.6 (release code name “Push”)

New functions for providing and reviewing Merkle evidence

ZeroMQ notifications to detect duplicate expenses

(WIP) p2p broadcast of duplicate expense detection to enable network-wide detection.

mAPI v1.2

Push-based recall notifications for Merkle proofs and duplicate expenses

SPV channels v1.0.0

An end-to-end nano-service for encrypted messages with push function, which offers a Bitcoin user a constant presence and offers a uniform interface for the processing of online and offline messages.

· As an always-on service, it solves the NAT traversal problem by allowing two parties to communicate via a blind intermediary in a private channel, so that only outgoing connections are required. In principle, this is similar to the seamless functioning of services such as TeamViewer, Skype and Zoom, even between users who are behind firewalls, but with full e2e encryption.

SPV Channels is a new offering from the Bitcoin SV Infrastructure team. Think of channels as something that resembles an IMAP mail server. Messages are collected for you when you are offline, but when you are online they are forwarded directly to you. When you and another party are both online the experience is similar to a direct connection, but e2e is encrypted by default and without the terrible format requirements of the mail header format. It can be integrated with Paymail, but the server itself has no visibility of the content and is completely independent of it. That being said, it’s not very Bitcoiny at all. However, it fills a critical void in the workflow of a peer-2-peer Bitcoin interaction.

Using SPV channels goes beyond that – to almost all off-chain coordination issues in Bitcoin and even outside of Bitcoin, such as:

Coordinate multisig or threshold signature groups

Issue notifications for wallets

General notification for everything

A base layer for a new generation of self-confident email and / or instant messaging.

A use case with mAPI

Earlier versions of mAPI (formerly known as the Merchant API) solved some key issues such as billing and sending transactions directly to the miner. Getting responses from miners about acceptance is easy as it can be a direct response to the submit request. However, there are events that occur after this user-miner connection is closed, e.g. B. Receiving an SPV proof when the transaction is integrated into a block. We introduced a rudimentary mechanism to get updates by querying mAPI for transaction status. However, this is inefficient and time sensitive for a particular use case dealing with double spend attempts so a better mechanism was required.

Enter the push model. Registering for an event callback is a common programming paradigm. SPV channels enable this for user-miner interaction. When you register for a callback, you usually need to provide a URL to which the callback will always be active. This is unlikely to be able to be provided by cellphone users.

Enter SPV channels. A hosted service (or self-hosted if you prefer) that acts as a channel for the user to receive messages. If the user is online, they will receive the messages immediately. When offline, the messages will be saved and forwarded as soon as the user goes online. In fact, the first internal version of SPV channels was unimaginatively referred to as “Store and Forward”.

So the workflow looks something like this:

1. Customers and dealers can find each other via the Paymail service identification. and establish bidirectional encrypted communication via SPV channels.

2. Merchant finds a miner’s mAPI via MinerID.

3. Merchant requests a fee offer from the miner via mAPI.

4.Merchant sends the customer a transaction specification via BIP270 with the required fee, payment amount and other requirements for the transaction.

5. The customer sends the transaction (possibly together with Merkle proofs and other requested information) to the merchant.

6.Merchant sends the transaction to Miner via mAPI and registers an SPV channel URL for callbacks.

7. If a duplicate issue is detected, the miner will send a message to the SPV channel which the trader will immediately receive when online.

8. As soon as the transaction is summarized in a block, the miner sends a Merkle proof to the SPV channel, which the merchant’s wallet can retrieve and save in its database.

9. Optionally, the retailer sends the Merkle proof back to the customer via his SPV channel.

Who pays for all of these services?

In the early days, the cost of running these services will likely be minimal, so someone is likely to offer them for free. But at some point the cost of such hosted services will add up. Wallets, miners, and payment processors can cover some of these costs as part of their service offering.

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

1. Hosted Paymail

2.Hosted SPV Channels Service (can be provided by the paymail provider)

3.Merkle proof delivery (not necessarily from the miner mining the transaction)

4. Duplicate expense notification (can monitor one or more miners for you)

It will be interesting to see how the Bitcoin SV ecosystem evolves and what types of companies choose to offer these services.

For some reason, suppose you request each of the 4 services from 4 different service providers. All are services that are provided as part of a transaction. This is a perfect use case for adding nano payment expenses to a transaction. One or ten satoshis to each service provider for a one-time service with no implicit commitment to anyone, which creates a strong incentive for them to provide the service well.

The future of SPV channels

The first implementation of SPV channels published today provides the basic framework and is currently only optimized for the desktop. Our short-term priorities are to provide mobile client libraries that use 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 that there is a lot of demand for a combined channel / paymail hosted service and we look forward to seeing who will be the first to offer it.

The future of SPV workflows

In what we unveiled today, we have offered solutions to the blocking problems for the entire SPV workflow. Many of these solutions can be improved and optimized, but the end-to-end use case is currently possible with these components. We assume that this entire workflow will be discussed a lot by the Bitcoin SV business operators and possibly changes or full alternatives will be proposed and accepted. For now, however, we have a foundation, a starting point, that consumer-facing product developers can immediately build on.

Copyright © Korea IT Times Unauthorized copying and distribution prohibited

Comments are closed.