Addresses should have been a temporary measure for Bitcoin, whether the original Bitcoin SV or the forked off Bitcoin Core. Something that bridges the gap between the initial release and a user friendly next step. Unfortunately, for lack of any better idea they were adopted as a central feature and canonised alongside a limited set of standard scripts. Worse still, they were intended to be phased out but the replacement of Paymail, a flawed system that never met it's promise and is inherently insecure and broken.
Let's work our way through from Bitcoin addresses, to standard scripts, to Paymail and finally to examining what we should be using instead.
This document is intended to look at addresses and identify why we use them and to suggest that they are unnecessary and should be phased out.
This address encodes two pieces of information, an indication of what type of script template should be used and the extracted part of the script template that differs. The supported script templates are either P2PKH, which is still the most commonly used template, or P2SH with which can no longer be used to store funds. And the differing part is a 160-bit hash of either the public key (P2PKH) or the real script that will be provided when any funds locked up in the script are spent (P2SH). The representation of the address is called base58, and was intended to represent the output script in a way where a user could transcribe it without confusing which characters they were transcribing.
Really.. really? A regular person who uses the future Bitcoin integrated into daily life in the real world does not want to even see this junk. The notion they should be expected to transcribe them is ridiculous. Yes, for us developers and niche hobbyests playing with wonderful and interesting toys on the bleeding edge, it is a very rough starting point we can use for now. That regular person won't even want to compare them. And any service or application that tries to make them do so, will be left in the dust by services which provide user-friendly alternatives. We already see malware relying on user fatigue to replace addresses in the user's clipboard, not noticing funds are redirected to the malware authors address which gets pasted instead.
A user should never see any kind of address. None. Not Bitcoin addresses and certainly not Paymail addresses. The problems with Paymail are covered later in this document. For now let's leave it at asserting that it is not anything like an identity and it is an insecure way to pay. The user's wallet or application should deal in real identity and solicit interaction in ways it can understand, and do so reliably and safely.
Each type of base58 address represents a given type of script template, whether P2SH or P2PKH. In order for an application to know what to do with an address it receives, it has to understand what kind of script template that address represents and how it can be used. Bitcoin Core by enforcing standard scripts and pushing custom scripts through the P2SH pathway, enforced a future of these unreadable and unuser-friendly addresses.
Bitcoin SV no longer has standard scripts. The ability to construct almost any script that the original release of Bitcoin allowed has made addresses a limiting factor. It also highlights the difference that knowing how to recognise and use script templates other than the limited base58 addressable forms makes. Someone using an application like ElectrumSV who wants to use the bare multi-signature script template does not have the ability to represent that in a way where any other applications can pay to it as they can to a P2PKH or P2SH address. This is a script template that dates from the original Bitcoin release, and not even any of the new fancy things that are now possible.
If an application naively accepts output scripts to pay to, it can of course do so. But there is an obvious requirement here that for the user's safety, the application should only be making payments when the user understands why and the application understands why. And the user should have some assurance about where the payment is actually going to.
The way an application is told by another party about the scripts they are to interact with and for what purpose, has to be explicitly communicated in some way. We already see that even for standard scripts like P2SH and P2PKH, the form used to communicate this is junk text that is hard to compare and painful to transcribe. There is no future in an ecosystem where we compound this with more address types, and all addresses should be resigned to only being seen by developers and advanced users -- but only when they are required to by circumstance.
A legacy payment is the mechanism with which payment to a Bitcoin address works. The wallet asks a blockchain indexer if it has seen payments to an address, and to tell it if it receives new payments to that address. As new transactions appear in the mempool or in new blocks, the indexer notifies the registered wallet. However, it was recognised that full chain indexing was not scalable nor even necessary. That P2P payments where Alice gave the payment directly to Bob, were better, and that we needed to move towards those. We'll come back to the P2P payment topic after we finish with legacy payments.
P2SH payments no longer work on Bitcoin SV. But P2PKH legacy payments are still possible and there is no real solution ready for use beyond them. However a bit of thought shows that we no longer need full chain indexing for this to work. That we can survive on P2PKH payments for now, until we get that forward looking usable solution. The wallet can ask the indexer to monitor for the usage of the P2PKH address for a fixed period of time before it shows that address to the user and allows them to give it out. It can use the existing payment URL format to encode an expiry date, where it is made clear to the payer that they can't pay past that point in time where the indexer will no longer be monitoring. And the indexer can pass any matches to the wallet when they happen if it is connected, otherwise it can pass any matches the next time the wallet connects or call out to an HTTP endpoint which may or may not be a peer channel that acts for the wallet when it is offline. This is called tip filtering and requires no indexed history to be stored.
Legacy payments to P2PKH addresses are not user friendly and hopefully they will be the fallback option when regular people want to flock to Bitcoin SV. But they are well documented and have a scalable path that can allow them to continue to be used until there is a better option.
When Paymail was created it was painted as a way for payments to integrate with email. Here we are five years later and it is an identity that is not an identity, that provides a way to do insecure payments that has nothing to do with email. It has turned out to be a distraction from the very real needs that we should have been focusing on.
People claim that it "was like a bank account" and that "people use email addresses to make payments in their financial service". These are shallow claims that get repeated but never examined. A bank account is an identifier provided by a regulated financial institution, where the processing of payments (and reclamation of mislaid funds) between institutions happens in formal ways covered by law and those regulations. Those services where people use email addresses have identified users who are represented on that service by their email address as a label. There is no real email integration, nor are there in the services regular people are actually using. A bank account is something we can pay to safely and securely, and Paymail addresses are not. Regular people have paid the tax of understanding and becoming familiar with these systems, and rely on the protections of their formal integration into the real world of finance.
Even the dream of payments based around actual email turned out to be confused and problematic. Ryan's Heartmail project was predicated on the notion that people would own their own domain and control their own email and Paymail-based services around it. Let's take a step back and look at email.
Regular people originally relied on their ISP to provide and administer their email. This eventually decoupled from the ISP, allowing users to change ISPs without losing access to their old email address, and moved to large multi-national corporations like Google (gmail), Microsoft (hotmail/outlook) and Apple (icloud/apple). Owning and managing a domain name is a pain point. Provisioning and administering a server is a pain point. And then there is administering and running an email server, a notoriously complicated and painful endeavour. It is no wonder that regular people use the large popular email providers.
We need real world identity. An identity that easily links in with the things regular people use on a day to day basis in ways they are familiar with. We can easily do secure payments that do not need any form of address, where you know and can prove you are paying to a contact. Paymail is none of these things. It has been an expensive five year distraction. Legacy P2PKH payments are a better option and more secure.
With a P2P approach Bob no longer needs to monitor the blockchain to find the payment from Alice, instead Alice gives it directly to him. Bob verifies it, broadcasts it and observes it is accepted into the mempool and not a double spend. Alice gets her purchase, Bob gets his payment. Both parties are happy. The payment can be a fiat stablecoin. It can be the official government digital currency form of one of the national fiat currencies. It can be a tokenised asset in exchange for any of these things.
The exchange does not have to be a payment. It can be data or the representation of a right of some kind or the lifetime of something. The limit is that the applications being used by both parties know how to handle the mutual exchange.
An email address is not an real identity. A Paymail identity is not a real identity. A real identity is your real world government identity, verified using standard forms of identity documents. Some countries even have APIs that can be integrated already that can verify that you are who you are and live at the address you claim you live at. That is a real identity.
When regular people can link their wallet to a respected and legitimate identity service which can attest to their identity or anonymous properties of their identity (perhaps age range, location, qualifications or more)
You do not need addresses. You can have a contact list with names, pictures and identity claims for each contact. You can know who Bob Barker is and have an identity key and other details attested to by a respected identity service. When you meet someone new or have them referred to you, you get something like a business card with secure checkmarks verifying that the data is legitimate.
When you engage in an interaction with them, and both your wallet and their wallet understand each other, you get an intuitive interface laying out that interaction in a custom easy to understand way. You can drill down on specifics, accept it or reject it. You never see an address or a transaction ID unless you choose to turn on the advanced/developers view.
There are a lot of interesting things happening on Bitcoin SV, but to some people it may look like not a lot of progress is being made. People don't know what the future system will look like, and some have developed options they imagine will be adopted as that system. But the only current usage is perhaps by developers and enthusiasts who enjoy playing with the cool toys that are being developed. Businesses do not yet see the ways in which integration with their products and services can benefit them, and anyone developing Bitcoin products and services has to pander to those other developers and enthusiasts as their pool of users. There's a lot of opportunity to build up products and services ready for when it becomes clear how Bitcoin can be integrated for best benefit by anyone with a suitable use case, but to do so it is unlikely you can fund it with earnings, and investment is likely a requirement.
Because we are in that drought of unclear direction, it is unclear what abstractions and forms of data and protocols we should be using. Maybe developers don't realise why we inherited addresses and assume they are more than they are. Who knows. But it is rare to see people eschew addresses, and new products and services often assume that because it is there and the alternatives are currently unclear, addresses must be used - whether Bitcoin addresses or Paymail.
Bitcoin addresses are a representation of the limitations of standard scripts, and are neither readable or easily comparable, and are being abused because of this by malware authors. With Bitcoin SV being no longer constrained to standard scripts we should discard them completely and move to P2P and start with P2P invoicing and a P2P identity, then we can evolve it to real identity.
Paymail addresses have likely caused stagnation in adoption of real identity and real P2P exchange. They are the opposite of P2P and are insecure, where neither the service hosting the sender or recipient advertise that you have no way of knowing your payment reached the recipient or was actually sent by the sender to you. Again we should move to a P2P invoicing protocol, P2P identity and as we can evolve it to a real identity.