A little over a week ago, Matt Corallo proposed BIP to coordinate making Bitcoin payments. Making payments in Bitcoin has always been a challenge in terms of coordination, both on-chain and off-chain with protocols like Lightning, for various reasons. When it comes to digital systems like email or payment systems like Paypal, Cashapp, etc., people are very used to the concept of a single fixed identifier. If you want to email John, simply email “john@”[insert domain]If you want to send some money to John on Cashapp, simply send a payment to @John on Cashapp.
This is the user experience that people are familiar with, and when it comes to ingrained user behavior and expectations about things, it is very difficult to get them to make a fundamental or drastic change in their behavior. If you give them a tool that requires it, that introduces a high degree of friction and will likely simply discourage most people from using that tool.
On-chain payments have a problem with this expectation, not because of the inability to have a fixed identifier (a single address), but because of the privacy implications of publishing a single address on the chain and having everyone you interact with use that. To pay you. It puts your entire payment history and ownership of coins in plain sight. If you rarely receive money every now and then, for example, when you get paid for work or settle tabs with people, it is not a burden at all to open your wallet and create a new address to access it. However, if you are receiving money frequently, especially in cases where you do not directly request payment, this represents a serious burden.
That's why tools like BTCPay Server were created, in order to lower the barrier of entry for people to run the infrastructure needed to automate receiving money without doing something as silly as publishing one address to each person who pays you for reuse. However, this requires running a server that is constantly available online. Although the project has significantly reduced the level of understanding required, it still represents a significant burden for a user who simply wants to be able to receive money passively.
The same goes for lightning except worse. The invoice is only valid for one payment. Unlike on-chain address, which can be reused although this is a terrible practice, a Lightning bill cannot be used. Once the invoice is paid or expires, any attempt to pay it will be rejected by the respective Lightning node. This dynamic led to the creation of the LNURL specification, as well as the Lightning headers built on top of it. LNURL is a protocol to connect to an HTTP server through a static IP address that can be shared once to get an actual Lightning bill for payment from the server. Furthermore, Lightning Addresses are a naming scheme on top of LNURL structured similarly to email addresses: John@[domain of LNURL server].
All of these solutions have drawbacks. Requirements to run additional software (HTTP server) that remains connected to the Internet at all times in addition to a Bitcoin wallet or Lightning node; Submitting a request to the BTCPay/LNURL server leaks the sender's IP address to the recipient; Relying on TLS certificate authorities.
Just use DNS
HTTP server tools such as LNURL when paired with Lightning Address domains are used to resolve the connection to the HTTP server. Likewise, all BTCPay servers are configured using domains rather than using raw IP addresses. Matt's vision is why don't we stop relying on HTTP and use the Domain Name System itself?
DNS allows you to associate TXT records with a specific domain name, creating small human (or machine) readable records that can be queried from DNS servers. In combination with Domain Name System Security Extensions (DNSSEC), DNS TXT records provide a mechanism that can be used to query payment information without the burden of running an HTTP server, as well as providing greater flexibility and openness. DNSSEC provides a number of tools to cryptographically sign DNS entries, including TXT records, with DNS keys inherent in the hierarchical structure of DNS. This provides assurance that the TXT record you are querying is a signed record distributed to DNS servers lower level than the local root server/key.
This realizes the real benefit of DNS as a means of fetching payment data: say goodbye to the requirement to run an HTTP server. A TXT ledger can encrypt a Bitcoin address on-chain (although the BIP specifically recommends against doing so if you're not able to regularly rotate new addresses to prevent address reuse), but more importantly it can also hold a BOLT 12 Lightning display. .
These records can be fetched from any DNS server, from your local server, from your ISP, or even from a public server like Google or Cloudflare. From this basic point, one of the shortcomings of HTTP-based solutions has been solved; You are no longer leaking your IP address to the person you are trying to pay. Now, if you use your ISP's DNS or a public server like Google or Cloudflare without a VPN or Tor, you are revealing your IP address to them; Obviously, BIP encourages DNS resolution support over a VPN or Tor for precisely this reason.
Combining this proposal with BOLT 12 removes the need to run plugins which is a very real security concern for unsophisticated users, and allows domain ownership alone to give users everything they need to have a mechanism to locate payment information using a simple human readable identifier. BOLT 12 requires no HTTP server, handles the actual invoice delivery over connections routed directly through the Lightning Network, and supports Views, a persistent identifier that can be used to find the onion's route to that Lightning node. The problem is that the offer is encoded as a huge random string like the invoice itself, making it a terrible human identifier that can only be read/used through the use of QR codes or copy and paste.
By storing the offer in a DNS TXT record, all a user needs to make a payment is the domain for someone to type into their wallet so they can fetch the TXT record, fetch the BOLT 12 offer, and then make the payment. They don't need to host any server or run any software other than their own Lightning node, DNS handles everything for them as much as BOLT Hosting 12. Provide someone that users willing to pay can find them.
Is this a completely unreliable system? No, is it much better than HTTP based systems? definitely. The problem with such problems is that there are certain expectations of user experience and behavior that most people have as much as digital systems are supposed to work in their minds. Without replicating that user experience, large groups of people will simply use alternatives that meet those user experience expectations. Given this reality, in trying to fit Bitcoin into the box of user experience expectations, the design goal should be to meet user needs with minimal mutual trust, minimal burden on users, and minimal possibility of losing privacy in new ways. I think Matt's BIP checks all of these boxes compared to existing solutions.
