Thinking Outside the Box for the Next Era of Bitcoin Cash

Bitcoin Cash is a remarkably reliable and useful cryptocurrency that could support a much higher level of transaction volume than it currently does. Why hasn’t Bitcoin Cash achieved mainstream adoption for payments and other use cases?

I have a couple of suggestions to improve Bitcoin Cash, both at a protocol layer and at an app layer, that I believe would make a big difference in the user experience. I think by focusing on consumer applications with great user experience, we stand a chance at growing Bitcoin Cash significantly.

Email Addresses

My top suggestion is to use email addresses as Bitcoin Cash addresses. This may sound unusual at first, but hear me out. Email addresses have dramatically improved user-experience properties and technical properties compared to the current format.

An email address takes this structure: [name]@[domain] such as john@example.com. I doubt everyone loves email, but everyone is familiar with this address structure.

Email addresses are both decentralized (because anybody can own a domain name) and federated (because, in practice, most people use a service provider). Because everyone is already familiar with email for sending and receiving messages, new users will have no barrier to entry learning to use the same address format to send and receive Bitcoin Cash.

And there are many reasons why this is far superior to the current format, thanks to including a user-friendly name part and the technically useful domain part.

For each domain, assume a “send” protocol which is a web API used at https://[domain]/cryptocurrency. The exact URL doesn’t really matter, and you can also use a .well-known file to customize the location, but ultimately the idea is to attach a discoverable API location to each domain.

Now that each domain has a standardized web API, you can do anything whatsoever at that URL, including getting a new address for sending.

Thus, the simplest protocol is to simply allow sending to an email address by getting a Bitcoin Cash address from the domain’s API. The user would never see the Bitcoin Cash address, only the email address.

Some developers might object: “but now you have to trust the server!” But in practice, you always trust the server and/or application you are dealing with anyway, unless you wrote your own wallet software. Letting every user specify a server they trust, which could be their own server, to deliver public keys enables many use cases and technical applications that are impossible with the current approach.

Consider:

• The server at [domain] does not have to have any private keys, only public keys, because new public keys can be determined deterministically from a master public key.
• You can query a new Bitcoin Cash address every time you send for recurring payments, for increased privacy.
• An off-chain cryptographic signature can be included from the server for an “address receipt” for auditability (enabling the sender to prove that they sent a payment to [name]@[domain], in case the server committed fraud and used a wrong address).
• You are not limited to one Bitcoin Cash address. Instead, the sender could query many addresses, making complex transactions possible, or even sending multiple transactions for a single payment, enabling privacy techniques like merge avoidance. This is impractical with ordinary Bitcoin Cash addresses, which would require manually giving many unique Bitcoin Cash addresses to someone per payment.
• You can send additional information over this protocol directly to the recipient, such as merkle proofs, enabling SPV and other advanced techniques.
• You are not limited to one cryptocurrency. The same self-custodial wallet software can host many different cryptocurrencies, and the same email address can be used for all of them. For instance, a new protocol can be created for each type of cryptocurrency at https://[domain]/cryptocurrency/[type] where [type] is the name of the cryptocurrency, such as BCH or BTC.
• You are not even limited to cryptocurrencies. You can send end-to-end encrypted messages from email address to email address using this idea, enabling upgraded truly end-to-end encrypted email for the first time, both in a way backwards-compatible with email, but completely ridding us of every aspect of the legacy email protocol except for the address format.

Note that while some custodial wallets may already use email addresses, that doesn’t mean that email addresses only work for custodial wallets. Email addresses work for self-custodial wallets with no changes in trust model (the user de facto trusts their wallet software to do what it says - keep private keys client-side). Email addresses do not require any more trust than what the user already has in their wallet software.

Domain Names

We can go further than email addresses for improving the user experience and technical properties of Bitcoin Cash. If the Bitcoin Cash community is willing to consider important changes to the protocol, we can make some dramatic improvements for users and developers by adding domain names into each block.

The reality is that full nodes are not the core of the Bitcoin Cash network, mining pools are. If each mining pool puts their domain name in a block, we will gain some remarkable properties.

First of all, note that there are only a handful of major mining pools. Consider that with ten-minute blocks, in a one-month period there can be no more than about 4032 blocks, implying an upper limit of 4032 mining pools. In practice, the number of mining pools is more like 10 or so. These 10 mining pools mine the vast majority of blocks.

If each mining pool puts their domain name in each block, either by changing the block header, or, more easily, by adding it into an input of the coinbase transaction, we can then establish a protocol for mining pools to communicate with each other via web APIs hosted at their domain.

Once you have such a protocol, you can do real-time queries to the mining pool network to know that a transaction will be confirmed. You can know the amount of hash power of a mining pool by simply counting recent blocks. Although any transaction on Bitcoin Cash that is unconfirmed is highly reliable in practice, it may technically be double-spent. But if all mining pools are identified and agree that a transaction is valid, then you can be certain that it will be confirmed, by knowing that greater than 50% of the hash power agrees. This changes confirmation from “high probability” to “certain” - a very important difference for usability.

Not only would mining pools be able to communicate with each other, but wallets, apps, and users could easily query the mining pools to get blockchain information. Think of this mining API as a sort of standardized blockchain explorer API.

The fundamental idea here is that once we recognize that mining pools are the core of the network, and are not anonymous, there is no reason not to add a domain name into each block to enable validation of mining pool identity and then querying the mining pools in proportion to hash power.

Conclusion

Bitcoin Cash is a remarkable cryptocurrency that has not yet achieved mainstream adoption. I believe that by focusing on user experience and technical improvements, we can grow Bitcoin Cash significantly. I have suggested two important changes to the protocol that I believe would make a big difference in the user experience: using email addresses as Bitcoin Cash addresses, and adding domain names into each block.

I hope that the Bitcoin Cash community will consider these ideas and others to improve Bitcoin Cash for the next era.