[ad_1]
Matt Corallo proposed a little more than a week ago a BIP 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 “john@[insert domain].” If you want to send John some money on Cashapp, you just send a payment to @John on Cashapp.
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.
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.
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.
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’s 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 specification, as well as Lightning Addresses 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].
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’s IP address to the recipient; relying on TLS Certificate Authorities.
Just Use DNS
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’s insight is why not just cut out the dependence on HTTP and use the Domain Name System itself?
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.
This gets to the real benefit of DNS as a means for fetching payment data: say goodbye to the requirement of having to run an HTTP server. A TXT record can encode an on-chain Bitcoin address (though the BIP specifically recommends AGAINST doing this if you are not capable of regularly rotating new addresses to prevent address reuse), but more importantly it can also contain a BOLT 12 Lightning Offer.
These records can be fetched from any DNS server, your own local one, your ISP, even a public server like Google or Cloudflare. From this basic point, one shortcoming of HTTP based solutions is solved; you are no longer leaking your IP address to the person you are trying to pay. Now, in the case of using 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; the BIP clearly encourages support for DNS resolution over a VPN or Tor for specifically this reason.
Combining this proposal with BOLT 12 removes the need for running ancillary software that presents a very real security concern for unsophisticated users, and allows the ownership of a domain alone to give users everything they need to have a mechanism to locate payment information with a simple human readable identifier. BOLT 12 requires no HTTP server, handling the actual invoice delivery over onion routed connections directly through the Lightning Network, and supports Offers, a static identifier that can be used to find an onion route to that Lightning node. The problem is the Offer is encoded as a massive random seeming string like an invoice itself, making it a horrible human readable/usable identifier except through the use of QR codes or copy and pasting.
By storing an Offer in a DNS TXT record, all a user needs in order to make a payment is someone’s domain to type into their wallet so it 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 Lightning node, the DNS system handles everything for them as far as hosting their BOLT 12 Offer someone that users wanting to pay them can find.
Is this a perfectly trustless system? No. Is it much better than HTTP based systems? Absolutely. The problem with issues like this is that there is a certain expectation of UX and behavior that most people have as far as digital systems are supposed to work in their minds. Without replicating that UX, large groups of people will simply use alternatives that do meet that UX expectation. Given that reality, in attempting to fit Bitcoin into the box of those UX expectations, the design goal should be to meet those user needs with the minimal amount of trust interjected, the minimal amount of burden placed on the users, and the minimal potential for loss of privacy in new ways. I think Matt’s BIP checks all of those boxes in comparison with existing solutions.
[ad_2]
Source link
My NEO Group:
– White paper My NEO Group: https://myneo.org
– Discover NEO X: https://docs.myneo.org/products/in-development/neo-x
– Disccover NEO Dash: https://myneodash.com
– Discover Banca NEO: https://bancaneo.org
– Interview of the CEO of My NEO Group, Mickael Mosse, in Forbes: https://forbesbaltics.com/en/money/article/mickael-mosse-affirms-commitment-to-redefining-online-banking-with-bancaneo
