Matt Corallo proposed a little more than a week ago a BIP<\/a> for the coordination of making Bitcoin payments. Making bitcoin payments has always presented something of a challenge in terms of coordination, both on-chain and off-chain with protocols like Lightning, for different 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 static identifier. If you want to send John an email, you just email \u201cjohn@<\/a>[insert domain].\u201d If you want to send John some money on Cashapp, you just send a payment to @John on Cashapp. <\/p>\n This is the user experience that people are familiar with, and when it comes to entrenched user behavior and expectations with things it is incredibly difficult to push them into a substantial or sharp change in their behavior. If you present them with a tool that requires that, it presents a large degree of friction and more than likely is simply going to disincentivize most people from using that tool. <\/p>\n On-chain payments run into a problem with this expectation, not because of an inability to have a static identifier (a single address), but because of the privacy implications of posting a single on-chain address and having everyone you interact with use that to pay you. It puts your entire payment history and coin ownership in the public view of everyone. If you are only rarely receiving money now and again, i.e. when being paid for work or settling bar tabs with people, it’s not a burden at all to simply open your wallet and generate a fresh address to receive to. If you are frequently receiving money however, specifically in instances where you do not directly solicit the payment, that presents a serious burden. <\/p>\n This is why tools like BTCPay Server were created, in order to lower the barrier to entry for people to spin up the needed infrastructure to automate receiving funds without doing something naive like posting a single address for everyone paying you to reuse. However, this necessitates running a server that is constantly available online. While the project has drastically lowered the bar of understanding required, it is still a high burden for a user who simply wants to be able to passively receive money. <\/p>\n The same holds true for Lightning except worse. An invoice is only good for a single payment. Unlike an on-chain address, which can be reused even though it\u2019s horrible practice, a Lightning invoice cannot be used. Once the invoice has either been paid or expires the Lightning node in question will deny any attempt to pay it. This dynamic led to the creation of the LNURL<\/a> specification, as well as Lightning Addresses<\/a> built on top of it. LNURL is a protocol for connecting to an HTTP server through a static IP that can be shared once in order to grab an actual Lightning invoice to pay from the server. Building on top of that, Lightning Addresses are a naming scheme on top of LNURL structured similarly to email addresses: John@[domain of LNURL server]. <\/p>\n All of these solutions have downsides. The requirement to run an extra piece of software (an HTTP server) that remains online all the time in addition to your Bitcoin wallet or Lightning node; making a request to the BTCPay\/LNURL server leaks the sender\u2019s IP address to the recipient; relying on TLS Certificate Authorities. <\/p>\n HTTP server tooling like LNURL when paired with Lightning Address use domains to resolve the connection to the HTTP server. Similarly BTCPay Servers are all configured with domains rather than using raw IP addresses. Matt\u2019s insight is why not just cut out the dependence on HTTP and use the Domain Name System itself? <\/p>\n DNS allows you to associate TXT records with a given 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 in order to query payment information without the overhead and burden of running an HTTP server, as well as offer a bit more flexibility and openness. DNSSEC provides a number of tools for cryptographically signing DNS entries, including TXT records, with the DNS keys inherent in the hierarchical structure of DNS. This provides a guarantee that the TXT record you are querying is the record signed by and distributed to lower level DNS servers from the local root server\/key. <\/p>\nJust Use DNS<\/h2>\n