Reconcile Bitcoin Payments Using DNS

Matt Corallo proposed a BIP for Bitcoin payment reconciliation a week ago. Bitcoin payments have always presented difficult challenges in terms of coordination, both on-chain and off-chain, using protocols like Lightning for a number of reasons. For digital systems like email or payment systems like Paypal, Cashapp, etc., people are very familiar with the concept of a single static identifier. To email John, just send email to “john@(insert domain)”. To send money to John from Cashapp, simply send the payment to @John from Cashapp.

This is a user experience that people are familiar with, and when it comes to entrenched user behavior and expectations about things, it’s incredibly difficult to bring about any real or drastic change in their behavior. Providing a tool that requires this will create a significant level of friction and will likely disincentivize most people from using the tool.

This expectation is problematic, not because on-chain payments cannot have fixed identifiers (single addresses), but because of the privacy implications of publishing a single on-chain address and having it used by everyone who interacts with it. To pay you. Full payment history and coin ownership are public for everyone to see. If you only receive money occasionally, say when working or organizing a bar with people, it’s not a burden at all to simply open your wallet and create a new address to receive it. But receiving money frequently can be a serious burden, especially if you don’t ask for payment directly.

This is what tools like BTCPay servers do to lower the barrier to entry so that people can spin up the necessary infrastructure to automate the receipt of funds without doing something as naive as publishing a single address to everyone who pays for reuse. This is why it was created. However, this requires running a continuously available server online. Although the standard of understanding required has been significantly lowered through the project, the burden is still high for users who simply want to passively receive money.

The same goes for Lightning, except worse. Invoices are only suitable for single payments. Unlike on-chain addresses, which can be reused despite terrible practices, Lightning invoices cannot be used. Once the bill is paid or expires, the Lightning node in question will reject the payment attempt. This dynamic led to the creation of the LNURL specification and the Lightning addresses built on top of it. LNURL is a protocol for connecting to an HTTP server via a static IP that can be shared once to retrieve the actual Lightning invoice for payment from the server. Lightning addresses are also an LNURL-based naming scheme, structured similarly to email addresses: John@ (the LNURL server’s domain).

All of these solutions have drawbacks. Requirement to run additional software (HTTP server) that is always online in addition to a Bitcoin wallet or Lightning node. Requests to the BTCPay/LNURL server will leak the sender’s IP address to the recipient. Relies on TLS certificate authorities.

Just use DNS

HTTP server tools such as LNURL paired with Lightning Address use the domain to verify connectivity to the HTTP server. Likewise, BTCPay servers are all configured as domains rather than using raw IP addresses. Matt’s insight is why we shouldn’t just remove the dependency on HTTP and use the domain name system itself.

DNS allows you to associate a TXT record with a specified domain name, creating a small human (or machine) readable record that can be queried by a DNS server. DNS TXT records, along with Domain Name System Security Extensions (DNSSEC), provide a mechanism that can be used to query payment information without the overhead and burden of running an HTTP server, as well as providing more flexibility and openness. DNSSEC provides a variety of tools for cryptographically signing DNS entries, including TXT records, using DNS keys inherent in the DNS’s hierarchical structure. This ensures that the TXT record being queried is a record signed and distributed by a down-level DNS server on the local root server/key.

This brings real benefits to DNS as a means of retrieving payment data. That means saying goodbye to the requirement to run an HTTP server. The TXT record can encode an on-chain Bitcoin address (BIP does not recommend this unless you can regularly rotate new addresses to prevent address reuse), but more importantly it can also contain the BOLT 12 Lightning Proposal. That there is.

These records can come from any DNS server, local server, ISP, as well as public servers such as Google or Cloudflare. This basic point addresses one drawback of HTTP-based solutions. You no longer leak your IP address to anyone you want to pay. Now, if you use your ISP’s DNS or a public server like Google or Cloudflare without a VPN or Tor, your IP address will be public. BIP specifically recommends support for DNS resolution over a VPN or Tor for this reason.

Combining this offering with BOLT 12 eliminates the need to run auxiliary software, which presents a very real security problem to unsophisticated users, and domain ownership alone gives users everything they need to find their payment information as a simple person. A readable identifier. BOLT 12 does not require an HTTP server, handles actual invoice delivery over an Onion routing connection directly over the Lightning Network, and supports Offers, which are static identifiers that can be used to find the Onion route to the corresponding Lightning node. The problem is that the suggestions, like the invoice itself, are encoded into large random-looking strings, making them terrible identifiers that can be read and used by humans except by using a QR code or copying and pasting.

If you store the offer in a DNS TXT record, all a user needs to make a payment is someone else’s domain where they can get the TXT record, get the BOLT 12 offer, and then enter it into their wallet to make the payment. You don’t need to host a server or run any software other than Lightning nodes. The DNS system handles everything as long as you host BOLT 12. It gives users who want to pay money someone to look for.

Is this a completely trustless system? no. Is it much better than an HTTP based system? totally. The problem with issues like this is that there are certain expectations about UX and behavior that most people have as long as a digital system operates in their minds. If you don’t replicate that UX, many people will simply use alternatives that meet those UX expectations. Given this reality, in attempting to fit Bitcoin into the box of UX expectations, the design goal should be to meet user needs with minimal trust, minimal burden on users, and minimal potential. Privacy is lost in new ways. I think Matt’s BIP meets all these criteria compared to existing solutions.