|
|
Matt Corallo proposed a BIP for coordinating Bitcoin payments a little over a week ago. For various reasons, coordinating Bitcoin payments both on-chain and off-chain with protocols like Lightning has been a challenge. When it comes to digital systems like emails or payment systems such as Paypal and Cashapp, people are accustomed to the concept of a single static identifier. If you want to send an email to John, you simply send it to "John@[inter domain]." If you want to send money to John on Cashapp, you just need to pay @John on Cashapp.
This is a familiar user experience, and when it comes to ingrained user behavior and expectations, it's challenging to prompt substantial or abrupt changes in behavior. If you provide them with a tool they need, it generates significant friction, and most people are likely to be suppressed from using the tool.
On-chain payments face this expectation problem, not because it's impossible to have a static identifier (a single address), but because publishing a single on-chain address and having everyone who interacts with you use that address to send you payments compromises privacy. It exposes your entire payment history and coin ownership to everyone's public view. If you only occasionally receive money, for instance, when you receive work compensation or settle a bar tab with friends, it's no burden to simply open your wallet and generate a new address for receipt. However, if you frequently receive money, especially in situations where you don't directly request payment, it becomes a significant burden.
This is why tools like BTCPay Server were created—to lower the barrier for people to enter the necessary infrastructure, enabling them to automatically receive funds without having to do naive things like publishing an address for everyone paying them to reuse. However, this requires running a server that is always online. While the project greatly reduces the required understanding standards, it remains a high burden for users who only want to passively receive payments.
Lightning faces a similar challenge, but it's worse. Invoices are only valid for a single payment. Unlike on-chain addresses that can be reused, Lightning invoices cannot. Once an invoice has been paid or expired, the associated Lightning nodes will reject any payment attempts. This dynamic led to the creation of the LNURL specification and, built on top of it, Lightning Addresses. LNURL is a protocol that connects to an HTTP server via a static IP, sharing it once to retrieve the actual Lightning invoice for payment. On top of this, Lightning Addresses are a naming scheme above LNURL, structured similarly to an email address: John@[LNURL server domain].
All these solutions have drawbacks. Besides your Bitcoin wallet or Lightning node, you also need to run additional software (HTTP server); making requests to BTCPay/LNURL servers leaks the sender's IP address to the recipient; and dependence on TLS certificate authorities.
When LNURL is paired with Lightning Address, HTTP server tools like LNURL use domains to resolve connections with HTTP servers. Similarly, BTCPay servers are configured with domains instead of using raw IP addresses. Matt's insight is, why not eliminate the dependency on HTTP and use the domain name system itself?
DNS allows you to associate TXT records with a given domain, creating small human-readable records that can be queried from DNS servers. Combined with the Domain Name System Security Extensions (DNSSEC), DNS TXT records provide a mechanism for querying payment information without the overhead and burden of running an HTTP server, offering more flexibility and openness. DNSSEC provides many tools for encrypting and signing DNS entries, including TXT records, using inherent DNS key pairs in the DNS hierarchical structure.
This brings real benefits to using DNS as a means to obtain payment data: eliminating the requirement to run an HTTP server. TXT records can encode on-chain Bitcoin addresses (although BIP strongly recommends against it if you cannot regularly rotate new addresses to prevent address reuse), but more importantly, they can also contain BOLT 12 Lightning Offers.
These records can be retrieved from any DNS server, your own local server, your ISP, or even public servers like Google or Cloudflare. From this fundamental point, it solves one drawback of HTTP-based solutions—you no longer expose your IP address to the person trying to pay you. Now, if you use an ISP's DNS or public servers like Google or Cloudflare without a VPN or Tor, you will reveal your IP address to them. BIP explicitly encourages supporting DNS resolution via VPN or Tor for this reason.
Combining this proposal with BOLT 12 eliminates the need for auxiliary software, which poses real security issues for immature users, and allows ownership of the domain only, providing users with everything they need to have a mechanism to locate payment information with a simple human-readable identifier. BOLT 12 doesn't require an HTTP server, directly handling actual invoice delivery via the Lightning network through onion routing, and supports Offers, which is a static identifier used to find the onion route to that Lightning node. The challenge is that Offers are encoded as a massive random string, similar to the invoice itself, making it a dreadful human-readable/usable identifier unless using a QR code or copy-paste.
By storing Offers in DNS TXT records, all users need to make a payment is someone's domain. They input it into their wallet, and it can retrieve the TXT record, get the BOLT 12 Offer, and proceed with the payment. They don't need to host any servers, nor do they need to run any software other than their Lightning node; the DNS system takes care of everything for them, as long as they host their BOLT 12. People who want to pay can find someone willing to offer what they seek.
Is this a completely trustless system? No. Is it much better than HTTP-based systems? Absolutely. The question regarding these types of problems is that, as far as people's expectations of how digital systems should work in their minds, most people have certain expectations of user experience and behavior. Without replicating the user experience, many people will only use alternatives that align with their expectations. Given this reality, when trying to fit Bitcoin into the box of user experience expectations, the design goal should be to meet these user needs with minimal trust, minimal user burden, and minimal privacy loss. I believe Matt's BIP checks all these boxes compared to existing solutions. |
|
Post time 27-2-2024 20:59:58