A Bitcoin Improvement Proposal
BIP75 is an extension to the Bitcoin Payment Protocol (BIP70). It enhances the Payment Protocol to allow for a more secure and automated address communication process between wallets, where two parties can exchange payment information in a permissioned and private manner.
The 3 enhancements are as follows:
- Allow for 2 way identity exchange
- Identity exchange is encrypted to prevent man in the middle attacks
- Allows mobile wallets to safely use the Payment Protocol by encrypting data sent to Store & Forward servers, and otherwise extending the protocol to support those servers
The primary motivation for defining this extension to BIP70 is to improve the Payment Protocol’s secure compatibility with mobile wallets, enhance transactional privacy, and make Bitcoin transactions more human-friendly.
Bitcoin Transactions without BIP70
Most bitcoin users are used to conducting transactions by entering a recipient’s public address, the amount to transfer, and pressing send. All bitcoin transactions are ‘final’ once a payment is sent to a functioning wallet address and the transaction is confirmed on the Blockchain. This is great for eliminating fraud associated with double-spends, but presents a novel and even frightening experience for users that fear their funds could be permanently sent to the incorrect recipient, without a resolution process.
The Payment Protocol (BIP70)
Often referred to as “Payment Requests”, the Payment Protocol described in BIP70 allows wallets that initiate a payment to receive a message from the intended recipient’s wallet, with details such as the amount to pay and the identity of the recipient, before they are prompted to ‘click send’ and sign the irreversible transaction.
As described in the BIP70 abstract:
“[BIP70] describes a protocol for communication between a merchant and their customer, enabling both a better customer experience and better security against man-in-the-middle attacks on the payment process.”
Examples of this in practice are websites with ‘donate now’/’pay now’ buttons that users can click to initiate a bitcoin payment. Coinbase provides us with a video demo of this in action, in a blog post (video at the bottom of the post) that details their support for the Payment Protocol.
BIP70 extensions to the core Bitcoin protocol include:
- Human-readable, secure payment destinations — customers will be asked to authorize payment to a payment processor identified as “example.com” (or “Example, Inc.” if an extended validation certificate is used) instead of an inscrutable, 34-character Bitcoin address.
- Secure proof of payment, which the customer can use in case of a dispute with the merchant. information sent and stored off-chain
- Resistance from man-in-the-middle attacks (when a PaymentRequest contains a public key and signature). that replace a merchant’s Bitcoin address with an attacker’s address before a transaction is authorized with a hardware wallet.
- Payment received messages, so the customer knows immediately that the merchant has received, and has processed (or is processing) their payment. information sent and stored off-chain
- Refund addresses, automatically given to the merchant by the customer’s wallet software, so merchants do not have to contact customers before refunding overpayments or orders that cannot be fulfilled for some reason. information sent and stored off-chain
The Payment Protocol makes the experience of transacting with bitcoin more like other methods of payment that consumers are familiar with, both in stores and online. For example, think about the typical flow a consumer encounters when she makes an in-store purchase with a credit card:
- Initiate payment (swipe the card)
- Message with details about the payment (displayed on the POS after swipe)
- If the payment details are correct — approve the transaction (usually with a signature)
- Receive a receipt for your records.
Challenges: BIP70 & Mobile Wallets
BIP70 is great for creating this kind of experience for users making in-store or online bitcoin purchases, but doesn’t work well for peer-to-peer payments between mobile and desktop wallets. This is because mobile/desktop wallets, which are not always connected to the Internet, are unable to retrieve payment requests when they’re offline.
This issue can be tackled through the use of store-and-forward servers. As the name implies, store-and-forward servers can store Payment Requests sent to offline wallets, and then forward them to the intended recipient’s wallet once the server recognizes that it’s back online. While this allows BIP70 to work with mobile wallets, it does introduce new vulnerabilities to man-in-the-middle attacks/spying.
The New BIP: Encrypted Payment Requests & 2-Way Validated Identity
The newly proposed BIP adds an important extension to BIP70 that addresses this new security challenge, by prescribing that all Payment Requests sent to store-and-forward servers be encrypted at the application layer.
By encrypting Payment Requests before they’re sent to a store-and-forward server, mobile wallet providers can ensure that users’ Payment Requests are protected from being intercepted by a man-in-the-middle attack. Thus with this extension to BIP70, mobile and desktop wallets can securely use store-and-forward servers to store and serve Payment Requests, in a way that makes it impossible for server operators to spy on their transactions.
In addition to encrypting Payment Requests, the proposed BIP gives parties that initiate a Payment Request (referred to as an ‘Invoice Request’) the option to sign their Invoice Request with a certificate. This allows the payee (receiver) to validate the identity of the party they are transacting with before releasing payment details to them.
For example, let’s say Bob knows that he owes Alice money, and wants to receive an invoice with the amount owed, her payment address, and other sensitive details. Bob can now initiate this process on his wallet, by validating his identity to Alice in the form of a certificate, that can only be signed with his private key. Alice is then able to confirm that she’s really dealing with Bob before she releases the invoice (in the form of a Payment Request). Moreover, this allows Bob and Alice to have a human-readable record of their transaction that does not exist on a permanent, public ledger like the Bitcoin blockchain.
By enhancing the Payment Protocol to give a sender of funds the option to share their validated identity details with the receiver, via an extended validation certificate, the newly proposed BIP:
- Can make users’ personal bitcoin logs more human readable (records of ‘who’ you’ve transacted with rather than just 32 character public addresses)
- Give users the ability to decide who they want to release payment details to (and possibly store the decision to release payment details to this validated requestor so it only needs to be done once)
- Allows an entity, such as a political campaign to ensure donors match regulatory and legal requirements
- Allows for an open, standards based approach towards giving Bitcoin service providers the ability to meet regulatory requirements in a way that preserves end-user privacy.
The New BIP & Wallet Names
Wallet Names give Bitcoin users the ability to send and receive bitcoins with domain-style names like ‘jeff.company.com’ instead of a complicated, 32 character string. This could be used, for example, to add an “address book” feature to a wallet so users can send multiple payments to known entities without having to request an address every time. This type of feature is commonplace in popular apps like Venmo, but until now has not been possible with privacy-conscious mobile wallets for the following reasons:
- Using static public addresses holds the potential to seriously compromise end-user privacy, and address reuse is considered a security risk.
- BIP32 X-Pubs allow for the generation of unique public addresses for each new transaction that a user initiates, but watching an X-Pub chain for each person you wish to receive funds from is too resource-intensive for mobile applications.
- Moreover, there is always a risk that users will unknowingly send funds to an X-Pub address after the owner has lost access to the corresponding private key.
This BIP would allow Bitcoin wallets to maintain an “address book” that only needs to store each payee’s public key (eliminating reliance on static addresses), but a service like Wallet Names will be essential to keep the process user-friendly. It’s hard to imagine non-technical users utilizing an address book that requires them to acquire and input their friends’ BIP32 public keys, and Wallet Names make that process as easy as sharing an e-mail address.
Wallet Names work with BIP32 keys, so that users can share/use a single name for all of their Bitcoin transactions while a new wallet address is generated each time. This makes the process of sending/receiving bitcoin ‘human-friendly’ in a way that doesn’t compromise end-user privacy.
With the combination of the new BIP and Wallet Names, users can easily load up an address book by simply entering their desired recipients’ Wallet Names (no complicated public key required). When the user wants to make a payment, she can simply choose a recipient’s wallet name in her address book, and the wallet will do all the work in the background to communicate with the payee’s wallet, and receive a unique payment address to send to. If the payee’s wallet has been lost, replaced, or destroyed, no communication will be possible, and the sending of funds to a “dead” address is prevented.
Moving forward, I believe that the described extensions will allow Bitcoin wallets to provide users with a seamless, and easy to use experience that enhances both privacy and security. Improvements to the Core Bitcoin Protocol should not be taken lightly, and the research and work dedicated to this project showcases our commitment to providing the entire ecosystem with standards that position Bitcoin to appeal to less-technical users as the ecosystem continues to expand. We’d love to hear your thoughts as we all work together to move bitcoin and blockchain technology forward.