|Proposers||Andy Mee, Ryan X Charles, Miguel Duarte|
|TSC Sponsor||Masumi Hamahira|
|Authors||Andy Mee, Miguel Duarte|
|Reviewers||Curtis Ellis, Dan Dragon, Darren Kellenschwiler, Lorien Gamaroff, MrZ, Rafa Seibana, William Devine, Xiaohui Liu|
Bitcoin applications are in their infancy. There is a need for parties to be able to identify each other and exchange messages securely, confidentially, and with mutual authentication. A number of technologies work together to deliver this need, with Paymail at the core.
The Paymail protocol solves for service location and capability discovery based upon a human-friendly identifier, formatted similar to an email address. It defines a trust and security model, under which the above message exchange properties may be achieved. The protocol also defines an extension mechanism that allows for applications across a range of industries to benefit from the core Paymail features.
As an existing standard looking to be adopted via the Technical Standards Programme, the need for Paymail in the peer-to-peer payments space has already been validated (see below). Further explorations within informal working groups seek to expand the capabilities of Paymail-compatible applications across a range of businesses and use cases. Having a robust, clear base protocol, taking advantage of the TSC-defined standard document template and professional document writer services, would enable more business, individuals, software and services, to adopt Paymail. With increased adoption comes increased interoperability between systems, which reduces friction for users and businesses alike.
The core of the Paymail proposal focuses on interoperability between systems, specifically on identity, service discovery, and feature negotiation. Care has been taken to assure confidentiality and mutual authentication may be achieved in any given message exchange.
Businesses and individuals who use Bitcoin applications, or send and receive Bitcoin payments, benefit from a standardised approach to the problem of counterpart resolution. Having a standard approach to initiating peer-to-peer communication flows allows for more applications, and therefore businesses and individuals, to cooperate in application-specific ways.
Paymail is a key component in the scaling vision for Bitcoin SV itself. The SPV story is enhanced, allowing applications to scale with their own use of the chain, rather than the legacy model of scraping the global chain for transactions containing pertinent messages.
This proposal is to formally standardise an existing industry solution. The existing solution originated in a Bitcoin Association Wallet Workshop and featured input from the following companies:
- The Workshop
The existing solution has been adopted by a number of companies, most prominently by Centbee, Handcash and Moneybutton, as well as the RelayX exchange.
The authors listed at the top offer to serve as authors for the specification document.
There is no known prior art for the complete scope of Paymail, however existing products and solutions serve as prior art for subsets of Paymail functionality.
The most pertinent prior art is Handcash Handles, a system whereby users of the Handcash wallet can send Bitcoin to each other by using a human-readable alias, rather than legacy Bitcoin addresses. Paymail goes further than this solution by enabling interoperability between applications, rather than solving only for within a single application.
Inspiration was drawn from a number of existing technologies, including:
- IANA .well-known URI scheme
- DNS and DNSSEC
- Email (addressing and federation model)
The existing standard is documented at https://bsvalias.org. We propose that this standard is incorporated with the following changes:
- Further clarification of the two names “BSV Alias Protocol” and “Paymail”
- Emphasise the role of Paymail within the wider Bitcoin scaling vision and SPV
- Redefine the core of paymail to exclude payment-specific flows
- Move payment-specific flows out to Paymail extension specifications
- Fix sections 4.2 and 4.3 following feedback from an independent security review (there is a low-priority, low-severity issue that is easy to fix and existing implementations have committed to supporting)