Posted anonymously, 1 year ago

Safe Instant Transactions for Bitcoin

The original source code for Bitcoin had two ways to make payments. One was to pay to an IP address, and the other was to pay to a Bitcoin address. The pay-to-IP approach was removed because it was subject to main-in-the-middle (MITM) attacks.

Pay-to-IP is superior to pay-to-address. Instead of being removed, it should have been fixed to remove the MITM attack vulnerability. If that had happened, we would have more user-friendly, secure, and scalable wallet infrastructure today.

Today, we have protocols for paymail and BIP 270 which partially cover the needs of modern pay-to-IP. The other missing piece is Miner ID. In this article I will give an overview of what distinguishes modern pay-to-IP from pay-to-address, why it is better for everyone, and what work needs to be done to finish it.


By adding authentication and encryption, we can solve the MITM attack for pay-to-IP. The basic idea is that you first need some kind of naming system. These names need to be attached to public keys. The public key can then be used to authenticiate and encrypt data.

Paymail solves this issue. Paymail is a naming system (DNS and email addresses) that are attached to HTTPS end points serving a public key. Thus, payment information (such as low-level addresses) can be delivered in an authenticated and encrypted way.

One can use IPv6 to deliver transactions directly to a recipient. Although that is a highly desirable option for some use-cases, we will not discuss that solution in this article. Instead, we will discuss BIP 270, a protocol for delivering invoices and paying them.

In BIP 270, the sender requests an invoice from the recipient. In order to pay the invoice, the sender gives the transaction directly to the recipient. Not to the miners. The recipient verifies the transaction and responds with either “yes” or “no”. If the recipient accepts, they send it to the miners.

This is a key difference from how most Bitcoin payments work today. The way it works today is that the sender does not give the transaction to the recipient. Instead, they give the transaction to unrelated third-parties - the miners. The difference matters because this introduces a requirement on the recipient to monitor the blockchain to look for their payment, which is a needless cost.

In order for the recipient to validate their transaction, they need to know the inputs were contained in blocks. Thus, transactions should be delivered from the payer to the recipient along with all merkle proofs of inclusion of the inputs in blocks. This allows the recipient to know they are most likely receiving a valid payment before even asking the miners.

Although in most cases the recipient can ask miners if a transaction is valid, the recipient may be offline, such as in the case of an underground merchant. They may only be able to check the recent block headers on an infrequent basis, and want to be able to accept digital cash with a higher risk of fraud during the periods they are not connected to the internet. This can be accomplished with a low risk of fraud if merkle proofs are sent with the payment. We can extend BIP 270 to support merkle proofs to enable this.

A final missing piece of the puzzle is miner ID. In order for the recipient to know that a transaction is valid, it is extremely secure to ask the miners of all 1000 recent blocks. The recipient can monitor block headers and find the miner ID for each of these miners. They can then query these miners and ask each one of them whether a given transaction is valid. If all miners say it is valid and will be mined in the next block, then the recipient should accept the transaction. If one miner says it is a double spend, then the recipient should wait to see if it is accepted into a block before recognizing it as valid.

Thus we can see that by combining paymail, BIP 270, and miner ID, we have a modern form of pay-to-IP with no MITM attack possibility because everything is authenticated with paymail and HTTPS.

Comparison and Contrast

Let’s compare modern pay-to-IP (paymail, BIP 270, and miner ID) to pay-to-address.

Scalability. Pay-to-IP is more scalable than pay-to-address for a key reason. The recipient does not need to scan the blockchain to look for their payment. In a world where there are many users of Bitcoin, the volume of transactions is vastly higher than the number of transaction a given recipient is interested in. Especially when you consider the offline case, the fact that the recipient simply does not need to look at anything other than what they are interested in is a radical reduction in cost. While it is true that third party services to scan the blockchain already exist and are likely to continue to exist, the peer-to-peer design of Bitcoin eliminated the necessity in dependence on a third party for this case. There is no reason to pay a third party for a service that doesn’t need to exist.

Privacy. Pay-to-address does not support privacy techniques like merge avoidance. By leveraging BIP 270 and extensions to is, we can deliver a bundle of transactions to a recipient that pay from many inputs and pay to many outputs, maintaining a far higher level of privacy over merging many inputs and paying to a single output.

Usability. Paying to Bitcoin addresses is not user-friendly becasue the user has no idea whether the address is correct or not. Paying to a paymail is something the user can actually verify by eye. Furthermore, paymails can be easily copied and shared while mantaining all enhanced privacy properties.

Next Steps

The above protocols have been partially implemented already, but there is more work to be done to finish modern pay-to-IP.

Support for Paymail: Several wallets support paymail already, but we need full support, including exchanges, in order to achieve the full benefits of these protocols.

Extensions to BIP 270: We need a few extensions to BIP 270 to complete this vision, particularly 1) the ability to send many transactions per payment, 2) the ability to send merkle proofs with payments, 3) paymail authentication (as a replacement to the HTTPS authentication that we dropped).

Miner ID and associated APIs: It needs to be possible for wallets to get endpoints for the miners in recent blocks. That is the idea behind miner ID. Miners can then provide various services, including the ability to broadcast and verify transactions. When this is ready, recipients can validate each received transaction against whichever miners they prefer (presumably either all miners of the last 1000 blocks or so, or one miner they prefer). Additionally, there will need to be APIs to retrieve merkle proofs.


We have implementations of paymail, a spec for BIP 270, and some very good ideas for Miner ID. If we finish implementing all of these technologies, we can put them together to have modern pay-to-IP, a more scalable, private, and user-friendly way to make payments over pay-to-address.

Ryan X. Charles

Founder & CEO of Money Button

Previous Blogchain posts: