The BSV Paymail standard in a nutshell

Paymail, published previously as BSV Alias, is a collection of protocols for Bitcoin SV wallets that lets parties identify each other and exchange messages securely, confidentially and with mutual authentication. 

Instead of using complicated addresses like 17Dx2iAnGWPJCdqVvRFr45vL9YvT86TDsn, Paymail employs simple payment handles that are formatted like an email address.

The existing solution originated in a Bitcoin Association Wallet Workshop and featured input from Centbee, Conify, CopPay, ElectrumSV, Handcash, MoneyButton, nChain, The Workshop and Tokenized. 

In its current format, the solution has already been adopted by several companies, most prominently Centbee, Handcash and MoneyButton, as well as the RelayX exchange.

In this edition of our TTDR (Too Technical Didn’t Read) blog, we spoke to internal reviewer Darren Kellenschwiler about the first version of the Paymail standardised format, its value to Bitcoin service providers and end-users, and how you can get involved in shaping the outcome of this and future versions of the standard.

Technical Standards Committee (TSC): What changes have been made to the Paymail standard since it was published as BSV alias? 

Darren Kellenschwiler (DK): The brief answer is very few. We decided it was most crucial to clarify the core of the standard, which is service discovery, the process whereby you start with a paymail alias and arrive at a list of its capabilities. 

We separated out all the capabilities which were originally required and firmly defined them as extensions, leaving room for detailed improvement and clarification for each of them as their own standards in future. Otherwise, the changes were limited to a few formal recommendations for building capabilities and the addition of a .json file extension for the capability document to explicitly set the content type to remove ambiguity.

The bottom line is that we’re formalising the existing standards known as BSV Alias rather than going in and changing anything fundamental.

[Editor’s note: When talking about Paymail’s capabilities, we are referring to functions like:

• MultiSig authorisation, which lets you create a wallet where the use of funds are dependent on acquiring signatures from a number of specified individuals. 
• Sender Validation and Receiver Approvals, which lets a wallet’s owner ensure that they only receive funds from legitimate parties.
• Payment channels, which are useful for streaming data, operating a sequence of events, or operating with a live dataset in applications such as gaming.]

TSC: Where does capability discovery fit into the Paymail process? 

DK: The first step of establishing any connection between Paymail services is host discovery. This involves alice.com making a service request to bob.com to establish whether or not they have a Paymail service running at that domain in the first place. Assuming all is well, this gives alice.com a Paymail service endpoint to query.

Capability discovery is the process that follows from there: alice.com makes a second request, this time to bob.com’s Paymail service endpoint. Bob.com will then respond with a list of capabilities. These capabilities take the form of a BRFC ID key associated with a template URL.

Rather than being overly prescriptive on how to handle specific capabilities thereafter, we chose to defer that responsibility to each capability, the intention being to foster innovation while providing a solid backbone for the core functionality common to all paymail use cases.

TSC: Where do identities and BRFC specifications fit into this standard? 

DK: Identities in the paymail world are federated. Each service operator maintains the integrity of the identities within their domain. For example, a company may have a paymail for receiving income for a particular department within the business – let’s say ‘[email protected]’. That paymail service may need to sign certain messages passed to counterparties in the negotiation of a payment. It could be an invoice, purchase order, or receipt, for example. 

It is up to the operator of the paymail service at company.com to sign off on those messages in a way that fits the particular requirements of their business. It may be that a key management system is signing on behalf of a whole department, or even the whole domain, rather than just a single user. 

We wanted to ensure that it was possible for a domain to sign requests and responses, as well as specific users within that domain. To allow businesses to meet their individual needs, the signing of paymail messages between services was lifted from the core standard and will likely be standardised within specific capabilities.

Those capabilities are defined as BRFC specifications, which are all excluded from the core paymail standard.

TSC: So what happened to service discovery, BRFC specs, Public Key Infrastructure (PKI) and Basic Address Resolution that are mentioned as part of BSV alias?

DK: The capabilities defined in the 2019 BSV Alias Specification, namely PKI and Address Resolution, will have their own standards defined separately to ensure the separation of concerns. This is also true of the BRFC ID naming convention, which has been used for some time for a range of purposes within the Bitcoin ecosystem, defining anything from MinerID to Token Protocols to Paymail capabilities. By defining it separately, we can use it within Paymail without redefining the standard everywhere it’s used.

TSC: What other capabilities have you discussed for inclusion in future versions of the standard? 

DK: When discussing capability flows, we pondered the possibility of mandating signatures for all requests and the various different methods we could use for signing arbitrary request data. Ultimately we concluded that recommendation was preferable to mandate and that each capability would be able to define its own signature requirements if appropriate.

We expect many capabilities to enforce the signing of requests to improve counterparty identification, which will likely help with legal compliance, security, and privacy.

The general sentiment was to recommend standard Bitcoin message signing across the whole request body because all paymail service operators will already have Bitcoin libraries in their code that are capable of this type of signature.

TSC: Where do Paymail addresses fit into this process?

DK: One minor update to the standard not yet mentioned is the clarification on what language we ought to use when referring to entities within this standard.

So, a ‘Paymail Alias’ is what we call that thing which looks like an email address – it takes the form: [email protected].

Paymail Aliases are a way to identify a specific entity within a specific domain. It could be one person, or a department or a whole business. What it allows is for a Paymail service provider to quickly and securely handle requests on behalf of those entities while applying protocol rules and compliance steps on a case by case basis.

TSC: How does this standard serve service providers and regulators?

DK: Service providers will have an easier time getting started with a Paymail service since the capability requirements have been reduced, server options have opened up and the base protocol is now more firmly defined. This stability ought to encourage further investment in Paymail infrastructure, much like we’ve seen in Bitcoin SV itself due to the set-in-stone protocol.

Although this standard doesn’t directly serve regulators, it gives Paymail service providers a base layer on which to build their regulatory compliance. What we’re trying to move towards with Paymail is having a four-step process where there is a purchase order, invoice, payment and receipt. 

Imagine these steps taking place between paymail services where each message is being signed by either the originator or the beneficiary of the funds. Because we are dealing peer-to-peer and have convenient access to a PKI, we should be in a very good position to include encrypted compliance data for both parties within these communications. We also have the ability to deny Paymail requests programmatically, which could be useful for preventing payments from or to sanctioned entities.

TSC: How does this standard benefit end-users?

DK: When it comes to people who use Bitcoin, the standard will be valuable because it creates an experience that most people are familiar with. Conceptually, Paymail is the same as the emails we use every day: there’s a user at a particular domain. 

I think people can intuitively understand that if they’re sending money between domains, the policies and the compliance stuff is all handled by the domain. In contrast, the funds that are travelling to and from an account is handled by the local part in front of that domain. If you compare it to the prior alternative, which was just a Base58Check-encoded hash of a public key, Paymail is a huge improvement.

It’s also worth mentioning that Paymail helps us move towards a world where we are not confined to only using standard Bitcoin scripts. The original address format refers to a particular standard Bitcoin output script, whereas Paymail leaves that up to the host. So, for example, a host might want to receive money, perhaps it’s a wage or salary, into a multi-sig script or some novel script that is specifically designed for a higher level of security. 

Paymail puts all that technicality in the domain hosts control so that different hosts can operate peer-to-peer, completely interoperability, while having different levels of security depending on their particular customers’ needs. This could incentivise competition between paymail service providers to find new and improved scripts, lower fees or convenient protocols for a smoother user experience.

TSC: What is Paymail’s role within the wider Bitcoin scaling vision, and where does SPV fit in? 

DK: Early web wallets would have done something along these lines: somebody wants to pay money to the wallets, so they generate a new address. A payment is made to that address and broadcast to the Bitcoin network via some type of node that the originator’s wallet runs. 

Assuming that the sender and the receiver wallets are owned by independent organisations, the receiving organisation has to listen to every Bitcoin transaction hitting the network thereafter to look for any transaction that contains an output to the address they’re interested in.

Either they’re listening to every transaction on the network, or someone else is, and they’re repeatedly calling an API to that node saying, ‘Is there any money at this address? Is there any money in it?’ Eventually, once a transaction does appear in the node’s mempool or within the API’s response, the recipient wallet says, ‘OK, this money received by the address is supposed to be the transaction I’ve been waiting for. I’m going to include that in my own database to indicate that it’s a UTXO that this specific user will be able to spend.’  

The process relies on a lot of listening and a lot of data sifting – like looking for a needle in a haystack. Imagine Bitcoin scales as planned to hundreds of thousands or millions of transactions every minute. That’s going to be an unbelievable amount of effort for an extremely simple task.

Paymail helps us here through its peer-to-peer capabilities. Two parties can negotiate the formation of a transaction and simply pass it directly to one another via Paymail endpoints.

That’s the reason that Paymail’s going to help us cope with huge scaling: it’s no longer necessary to listen to every transaction on the network. You can only receive transactions that you’re interested in. There’s no need for wallet operators to have massive overhead just because the network is huge. You can build your infrastructure specific to the number of customers you have. If you’re a small company that’s only interested in a few thousand transactions, you can simply validate those transactions and nobody else’s. 

SPV or Simplified Payment Verification comes in when paymail service providers move from running the full Bitcoin client software, which listens to any and all transactions, to an extremely lightweight Bitcoin client which listens only to block headers – that’s 480 bytes per hour rather than the 6GB (or more) required otherwise. Using these block headers and the Merkle proofs from Merchant API (mAPI) broadcast callbacks, services are able to drastically reduce operational costs while maintaining a provably valid UTXO set for their users.

As Paymail reduces the barriers to entry, we expect to see a lot of small businesses and applications entering the arena by adopting this standard.

How to participate in standardising Paymail

If you didn’t contribute to the drafting phase of this standard, but would still like to participate, we have good news.

Every BSV technical standard goes through an entire life cycle, from a drafting phase to an internal review phase and finally to a public review phase. This public review phase is critical for ensuring openness of the process, transparency of what’s in development and an opportunity for anybody affected by the standard to check that it addresses their requirements.

The Paymail standardised format will move to the public review stage in September 2021, so make sure you register as a contributor so we can get in touch.