Standardize SPV and Tokens for Five Billion Daily Active Users

Introduction

In order to get to five billion daily active users of Bitcoin it is important to implement and standardize Simplified Payment Verification (SPV) wallets with support for tokenized digital assets including major world fiat currencies like the US Dollar.

We can summarize these initiatives as follows:

1. Implement and standardize SPV wallets. SPV wallets, described in the original white paperbut never fully implemented, enable users to possess and transact in digital cash. Although the user will not know how it works, what is going on is that their device is automatically sending and receiving transactions from other people and entities and verifying the user’s own transactions. Not only does this enable every non-custodial use-case, such as small cash transactions, it is also important for the security of Bitcoin as a whole that the block headers are widely distributed in end-user SPV wallets. The wide distribution of block headers is what prevents nodes from committing fraud and is the central distinguishing feature of a public blockchain versus a private database. Not only do we need to implement SPV, but we need to do so in a way that is standardized and interoperable through the ecosystem.
2. Implement and standardize tokenized digital assets on Bitcoin. Most people will not consciously send and receive Bitcoin. Instead, they will send and receive their local fiat currency or other digital assets such as stocks and bonds. Under the hood, Bitcoin is being used to pay nodes to stamp their transaction to the blockchain. But the costs are so small as to be negligible to most users. In order to get tokens going on Bitcoin, we need both the technical protocols to do so as well as the businesses (and maybe governments) to back the assets. It is important that these protocols are standardized so that they can be widely implemented and used throughout the ecosystem.

This is not a complete list of tasks that we must finish to get to five billion daily active users. We need to learn, build, test, iterate, rebuild, educate, market, sell, and over again just like any other industry. In this article we are going to concentrate only on the technical standards portion of the initiative. Our goal is to standardize everything necessary to get to five billion daily active users.

The Technical Standards Committee

The Bitcoin Association recently announced the Technical Standards Committee (TSC). The goal of the TSC is to establish and maintain a process for creating technical standards that use Bitcoin as the base protocol. The TSC will not actually create standards but will make sure that anyone who wants to create a standard has a clear process to follow that will result in real standards that are widely used.

Paymail (see also Money Button documentation) is an example of a standard we have already created, but that has not been formally standardized yet. We will create a formal standard for paymail and all other standards that we need to result in SPV and tokens across the ecosystem. Because tokens are so critical for use-cases for Bitcoin, and because token protocols are highly linked to many possible standards related to SPV, we include the token roadmap alongside the SPV roadmap.

Money Button and other companies are going to follow the process outlined by the TSC to start standardizing the future of wallets, including most especially SPV and tokens. This article motivates the standardization process so as to increase collaboration across the ecosystem, since standards require wide agreement by their nature.

The Definition of SPV and Tokens

There are no SPV wallets right now. This is a bit surprising considering SPV was described in the original white paper. Why haven’t any wallets actually implemented SPV?

Essentially, SPV has been overlooked because Bitcoin has been widely misunderstood and mis-implemented. Many people who got involved in Bitcoin were motivated to do something other than create the plumbing of the world economy. Their vision did not require scale, security, user-experience, or legality, so they never implemented SPV.

For those of us who want world adoption and who believe that the original vision for Bitcoin will get us there, we need to take care of the basics now. It is our responsibility to make SPV and tokens happen.

Non-custodial wallets currently exist, but do not go far enough for real SPV. The properties of an SPV wallet are as follows:

1. Transactions must be sent peer-to-peer. There is no reason for a payer to rely on a transaction to be relayed through nodes when they could hand over the transaction peer-to-peer directly to the recipient. This allows for instant transactions and is far more scaleable as it does not require that the recipient scan the blockchain or subscribe to a service to find their payment.
2. Transactions must include inputs and Merkle proofs. In order for the recipient to validate their transaction while offline, it is important that they can see the input transactions and inclusion proofs (Merkle proofs) for the inputs. The input transactions are necessary in order to validate the transaction and the Merkle proofs are necessary to know the coins originally came from the blockchain. Although many people will be online when receiving a transaction, it is important that our protocols do not exclude realistic use-cases, and internet connections are not 100% reliable. The offline use-case is also important for future extensibility to support payment channels which aren’t sent to nodes.
3. Wallets must track the block headers from the nodes. The end-user wallet can track the latest block headers from the nodes using a standardized form of Miner ID and the Merchant API. If it is ever the case that a node commits fraud such as by changing the block headers, it is important that the block headers are widely distributed to prevent this. This does not require that end-user wallets do anything expensive (SPV is cheap) but it does require that wallet developers are conscious to do SPV properly to make sure this security mechanism exists.

Tokens need the following properties:

1. Standardized token protocol, or at least a wrapper protocol. We do not currently have a standardized token protocol, but there are several in development. If possible, it is desirable to have only one standard so that there is less for businesses to implement. However, some token protocols may be more appropriate for some use-cases than others. To allow for this, it may be better to standardize a token wrapper that allow us to use tokens in an interoperable way across services without worrying about the details inside each protocol. This will allow a market of many different protocols to exist while still limiting the amount of work businesses have to do to implement new protocols.
2. Real world businesses or governments that back assets. Tokens are not useful if they do not have value. It is important that we have real-world stocks, bonds, and fiat currencies. Each of these asset classes have many different types of assets issued by governments or corporations all over the world. There can be many parallel initiatives in places that solve different pieces of this puzzle. The token protocols must be developed in collaboration with these businesses to make sure the protocols will actually be used.

SPV and tokens, by their nature, require interoperable standards. A wallet that implements SPV and tokens in a proprietary way does not have any advantages over systems that already exist like centralized payment and data management. In order to get the benefits of Bitcoin, these things must be standardized to enable a competitive market.

Why SPV and Tokens Matter for Five Billion Daily Active Users

SPV and Tokens are prerequisites for five billion daily active users for the following reasons:

1. SPV is necessary to scale Bitcoin. As the volume of transactions increases on the network, the cost of running the node software increases. It is already cost-prohibitive for normal users to run the node software and it will only get more expensive. It has always been the intention that end-users run SPV, which requires computational power low enough that even feature phones can do it. Widely deployed SPV is the only way we get to five billion daily active users.
2. SPV is necessary for the security of Bitcoin. Oddly overlooked, it is necessary that the block headers are widely distributed for Bitcoin to be secure. If everyone has the block headers, then no one can unwind the blockchain. Some people have promoted the idea that everyone should run the node software, which would result in everyone having the block headers, but this will not work because it is cost prohibitive. However, SPV is extremely cheap and scaleable, so it is a way to distribute the block headers widely, almost for free.
3. SPV is necessary for private Bitcoin. Bitcoin enables users to really own their data and their money. For many transactions, users desire privacy. Digital cash in SPV wallets enables genuinely private transactions. Only the user and the recipient of the funds know who are the participants of the transaction. As the scale of Bitcoin increases, the privacy increases because finding a transaction is like finding a needle in a haystack that keeps getting bigger. Users do not get these benefits if they must rely on trusted third-parties to transact on their behalf, because then the trusted third-party knows everything.
4. SPV is necessary for usable Bitcoin. Bitcoin enables a better user-experience than the traditional payment system for many use-cases, especially small cash transactions and micropayments. Small cash transactions do not require Know-Your-Customer (KYC) compliance, meaning that users do not need to scan their passport to use the service. Thus, it is easy to create and destroy SPV wallets without any action from the user. Using SPV as contrasted with a custodial wallet enables this use-case.
5. Tokens are necessary for usable Bitcoin. Tokens are key because most users will not care about Bitcoin (BSV) the digital asset. Instead, they will use a wallet that manages digital assets they actually care about, such as their local fiat currency for cash transactions or their investment portfolio including stocks and bonds. In most cases, users will not know they are using Bitcoin, in the same way that most users do now know they are using the internet.

SPV and tokens are necessary (but not sufficient) for five billion daily active users.

A Standardization Roadmap

The intention of this article is not to argue in favor of any particular standards (except existing standards, like paymail), but to argue that we need to have a standardization roadmap with small, modular standards that build up from the most basic standards to complex standards. Each modular standard will have some businesses interested and designing and implementing it. The fact that they fit together like puzzle pieces in a standardization roadmap will encourage more businesses to get onboard as they will see the end-game is something we all want.

As such, the following is a hypothetical standardization roadmap that will get us to five billion daily active users with SPV and tokens. Our hope is that businesses will provide feedback to this roadmap and that the standards we actually design and implement will solve the same set of issues, but may look different in detail to the particulars outlined here.

1. Paymail

Paymail as it was originally launched solves two important problems: A way to have names that are human-readable and machine-readable simultaneously, and a way to have an endpoint so that users can communicate (or their device can communicate on their behalf) with the other person or entity. We also had the ability to deliver addresses and public keys in the original paymail protocol, but these should be regarded as MVPs of paymail. The real value of paymail is that it is an extensible protocol for naming and queries and we can use it to solve many of the other issues for SPV and tokens. Most of the value of paymail will be delivered over time as it is extended to solve countless issues that rely on naming and queries.

2. Signatures, encryption, and Diffie-Hellman (DH) key exchange

Many protocols we want to use on top of Bitcoin will require data that is signed and/or encrypted. Money Button has already implemented on-chain and off-chain signatures and encryption and it is widely used around the ecosystem. We need to standardize signatures and encryption both for their own sake, but also to with the intention to be re-used inside other higher-level protocols discussed below, such as invoices and KYC.

Signatures and encryption often only make sense in the context of a shared secret and derivation of new keys, and as such as should include DH key exchange in these standards, along with any other cryptographic primitives that we plan to re-use in higher level protocols.

Dependencies:

1. Paymail. While not all signatures or encryption need to be attached to a paymail, many do. The public key in the original paymail protocol can be used for signatures, encryption, and DH key exchange.
2. KYC

Know-Your-Customer (KYC) regulations play an important role throughout the ecosystem. Any time a user needs to scan their passport of government ID, it is probably because of KYC regulations. Exchanges and wallets need to follow KYC regulations.

KYC can be irritating for the end-user if they have to scan their passport over and over. But a related concept is that the user likes to know what is the true identity of the party on the other side of the transaction, such as when making a purchase at a store or with another individual the user is trading with. This is good for end-users. A good solution to KYC can solve both issues, bringing both the user-experience benefits and eliminating the need to scan one’s passport over and over.

Essentially, the way to solve KYC is to allow third-party identity businesses like Jumio, or wallets or exchanges acting on their behalf, to sign a user’s paymail. This in combination with a standardized paymail authentication system will allow users to log into services and provide access to KYC information without first scanning their passport for the Nth time.

The same technology can be used to allow businesses to prove their identity to the end-user or to other businesses.

Dependencies:

1. Paymail. The proposed solution to KYC requires an extension to paymail that allows third-party KYC providers to sign the user’s paymail.
2. Signatures, encryption and DH key exchange. The paymail is signed, and private data will need to be encrypted.
3. Invoices

Users need to be able to send and receive invoices in a standardized way where a user with one wallet can send an invoice to another wallet. The notion of invoices will almost certainly replace the casual use of sending money to an address or a paymail. Invoices can be signed, authenticated, and tracked in a manner that makes accounting much better than without them. Invoices are standard in business and we should being them to Bitcoin.

BIP 270 is a proposed standard but is not yet widely implemented. We can use BIP 270, but we should be sure to also solve the problems that aren’t solved by BIP 270, including most especially signing the invoices, which will require KYC and related standards first.

Dependencies:

1. Paymail. This is who the invoice is to and from and how we do KYC.
2. Signatures, encryption, and DH key exchange. Either used on its own to sign/encrypt invoices or used in combination with KYC.
3. KYC. The ability to sign an invoice with your real name or company name.
4. NAT traversal

In order to send messages peer-to-peer over the internet, which is necessary for sending transactions and Merkle proofs, we need to worry about a highly technical issue with respect to how the ipv4-based internet works. This issue is Network Address Translation (NAT) which means the the router in between the user and the internet will automatically change their IP address and makes it quite difficult to get a message directly to them from the outside unless they have first established a connection. There are a variety of techniques for solving this issue. We will not propose any particular solutions here, other than to point out that the solutions involve a bit of cryptography, and as such any solution will likely require signatures and encryption.

Dependencies:

1. Signatures, encryption, and DH key exchange. Most likely will be used to authenticate the communicating party.
2. Peer-to-peer messaging

SPV requires that we send transactions peer-to-peer. Additionally, input transactions and Merkle proofs are also sent along with the payment. It is possible that a peer-to-peer messaging protocol could be used for other things besides transactions (such as user-to-user chat), but transactions will be the primary use-case.

Note that in this example I am assuming invoices are implemented first, but it would also be possible to build an invoice system on top of the peer-to-peer messaging infrastructure.

Dependencies:

1. Paymail. The name and endpoint of the person or entity the user is messaging.
2. Signatures, encryption, and DH key exchange. Cryptography is used for all messages for privacy and authenticity.
3. NAT traversal. The only way to get a message to an end-user is with some resolution to NAT traversal.
4. On-chain audit trail

Many protocols become more secure if events are logged on-chain, including the delivery of the receiving address in paymail. A standardized way to do on-chain logging would be useful.

Dependencies:

1. Paymail. Most likely the logs are tagged with a paymail.
2. Signatures, encryption, and DH key exchange. Most likely the logs are signed and encrypted with a paymail.
3. Peer-to-peer transactions, Merkle proofs, and input transactions

SPV requires that transactions themselves are sent directly to the recipient along with input and transactions and Merkle proofs so that the recipient can validate the transaction before sending it to a node.

Note that Money Button, Handcash, and Simply.Cash already have implemented a version of peer-to-peer transactions, which is a useful starting point for full SPV.

Dependencies:

1. Paymail. Where to send the transaction and where it comes from.
2. Signatures, encryption, and DH key exchange. Cryptography is used for all messages for privacy and authenticity.
3. NAT traversal. The only way to get a message to an end-user is with some resolution to NAT traversal.
4. Peer-to-peer messaging. Most likely this protocol is built directly on top of the peer-to-peer messaging protocol.
5. Tokens or token wrapper protocol

To make implementation easier, it is desirable that we have exactly one token protocol standard. However, given the history of our industry and the proliferation of projects creating token protocols, we may never have a situation where there is one dominant token protocol. Thus, we should consider standardizing a simple and flexible wrapper protocol for tokens that will enable token protocol developers to innovate inside of a standard wrapper so that.

ERC 20 tokens are the token wrapper protocol for Ethereum.

Tokens most likely do not depend on any of the other standards on this list, but may be used inside of them. For instance, the invoice protocol may not start out support tokens, but may need to be extended to do so.

10. Names and avatars for paymail

It would be useful to see names and faces next to the paymails in your contact list.

Dependencies:

1. Paymail. Who the name and avatar is for.
2. Signatures, encryption, and DH key exchange. For signing the names and avatars.
3. FATF compliance

The Financial Action Task Force (FATF) creates recommendations for national governments to regulate their financial industry. The recommendations are widely followed globally and we need to comply with them. New FATF recommendations require that businesses communicate KYC information for digital currency transactions. A protocol has already been created to solve this issue: InterVASP. We will have the option of using InterVASP or rolling our own or some of both.

Dependencies:

1. Paymail. Almost certainly our solution should be built on top of paymail to make sending and receiving transactions simple and compatible with our existing systems.
2. KYC. We also have the option of using our own KYC technology in the protocol.
3. Paymail authentication or “sign in with paymail”

Because Money Button adopted basic cryptographic operations including signatures, businesses have started to implement informal “sign in with paymail” by swiping Money Button. This is both a great solution to the user-experience issue of logging into a website without using yet another new username and password, and also a way to provide permissioned access to the user’s wallet. This makes countless applications possible and can be combined with other protocols like KYC to enable single sign-on into financial institutions without having to scan one’s passport yet again. This idea is probably best extended to become a protocol. We can call this paymail authentication or “sign in with paymail”.

Not only should this protocol allow one to sign in, but it should also include protocols for granting permission to the user’s wallet. For instance, the user can grant access to spend small amounts of money automatically or sign or encrypt or decrypt data automatically. These extensions could be added after the basic protocol for signing in is created first.

Dependencies:

1. Paymail. The name you use to log in is your paymail and we re-use the https endpoints for other properties of the protocol such as granting permission.
2. Signatures, encryption, and DH key exchange. These will be necessary for authentication and privacy.

Conclusion

We have argued that SPV and tokens are necessary to achieve five billion daily active users for Bitcoin. Five billion comes from the number of adult economic agents on the planet. If we can achieve this number, we can confidently say we have achieved global adoption for Bitcoin.

In order to have SPV and tokens, it is not just a matter of having one business implement them. SPV and tokens are by their nature protocols that need to be widely adopted if they are to be meaningful. They need to be standards.

The Technical Standards Committee (TSC) has been created to facilitate the creation of standards. The next step is a roadmap where businesses design and implement standards useful to them in a particular order that allows standards to be re-used inside of each other with smart dependencies. We start with the most basic standards first and build upwards.

What we have outlined in this article is a hypothetical roadmap for creating modular standards that will result in widely implemented SPV and tokens. The roadmap here does not propose any concrete standards other than the ones that already exist (particularly paymail). Instead, the roadmap is intended to provoke discussion and be referenced by companies already working on these standards. The intention is that the actual standards roadmap will be similar to this list, but most likely will include more, better solutions, after relevant discussions have taken place.

Ryan X. Charles is the founder of Money Button and a member of the Technical Standards Committee.

powered by  powpress

Standardize SPV and Tokens for Five Billion Daily Active Users.

By Ryan X Charles

8 sep 2020

https://powping.com/posts/ef72d7cb5e0ce6a7457dffc79f9c17e791cc50d18f049d5e89736c624d805a04