[
Matt Corallo proposed a BIP to coordinate Bitcoin funds a little bit greater than per week in the past. Making Bitcoin funds has all the time introduced a problem by way of coordination each on-chain and off-chain with protocols like Lightning for various causes. With regards to digital methods like e-mail or fee methods like PayPal, CashApp, and so on., folks have grow to be very accustomed to the idea of a single secure identifier. If you wish to ship John an e-mail, you merely e-mail “john@(insert area)”. If you wish to ship John some cash on CashApp, you merely ship fee to @John on CashApp.
That is the person expertise that persons are conversant in, and in relation to person conduct and expectations with issues it’s extremely tough to get them to make a considerable or drastic change of their conduct. When you current them with a device that requires it, it creates huge friction and can greater than probably discourage most individuals from utilizing that device.
The issue with on-chain funds comes with this expectation, not due to the lack to have a secure identifier (single handle), however due to the privateness implications of posting a single on-chain handle and having it utilized by everybody who interacts with you. There’s a purpose. To pay you. This places your total fee historical past and coin possession in public view for everybody. When you're solely receiving cash sometimes, i.e. when getting paid for work or settling bar tabs with folks, merely opening your pockets and creating a brand new handle to obtain in any respect. Not a burden. Nonetheless, in case you are receiving cash repeatedly, particularly in circumstances the place you don’t demand fee straight, it presents a severe burden.
Because of this instruments like BTCPay Server have been created, to decrease the barrier to entry for folks by creating the infrastructure wanted to automate receiving funds with out having to carry out a couple of easy duties, akin to Posting the identical handle for everybody to pay for re-use. Nonetheless, this requires operating a server that’s consistently accessible on-line. Though the mission has considerably diminished the extent of understanding required, it’s nonetheless an enormous burden for the person who simply needs to have the ability to obtain cash passively.
The identical is true for Lightning, besides worse. An bill is sweet for one fee solely. Not like on-chain addresses, which might be reused regardless of horrible observe, Lightning Invoices can’t be reused. As soon as the bill has been paid or expired the corresponding Lightning node will refuse any makes an attempt to make the fee. This dynamic led to the creation of the LNURL specification, in addition to Lightning Addressing on prime of it. LNURL is a protocol for connecting to an HTTP server by way of a static IP that may be shared as soon as to obtain the precise Lightning bill for fee from the server. Moreover, Lightning addresses have a naming scheme on prime of LNURL that’s structured equally to e-mail addresses: John@ (the area of the LNURL server).
All of those options have drawbacks. The necessity to run an extra piece of software program (an HTTP server) that’s on-line always along with your Bitcoin pockets or Lightning node; Making a request to the BTCPay/LNURL server leaks the sender's IP handle to the recipient; Trusting TLS certificates authorities.
simply use dns
HTTP server tooling like LNURL when mixed with a Lightning handle makes use of the area to resolve connections to an HTTP server. Equally BTCPay servers are all configured with domains moderately than utilizing uncooked IP addresses. Matt's perception is why not simply eradicate the reliance on HTTP and use the area title system itself?
DNS lets you affiliate TXT information with a given area title, creating small human (or machine) readable information that may be queried from DNS servers. DNS TXT information together with Area Identify System Safety Extensions (DNSSEC) present a mechanism that can be utilized to question fee info with out the overhead and burden of operating an HTTP server, in addition to a little bit extra flexibility and openness. Gives. DNSSEC offers a number of instruments to cryptographically signal DNS entries, together with TXT information, with DNS keys contained within the hierarchical construction of the DNS. This offers a assure that the TXT report you might be querying is a report signed and distributed by a DNS server decrease than the native root server/key.
This offers an actual good thing about DNS as a method of acquiring fee knowledge: say goodbye to the necessity to run an HTTP server. A TXT report can encode an on-chain Bitcoin handle (though BIP particularly recommends not doing so in case you are not in a position to rotate new addresses usually to stop handle reuse). , however extra importantly, it could additionally embrace a BOLT 12 Lightning providing.
These information might be obtained from any DNS server, your personal native server, your ISP, even public servers like Google or Cloudflare. From this primary level, a shortcoming of HTTP primarily based options is solved; You might be now not leaking your IP handle to the individual you are attempting to pay. Now, within the case of utilizing your ISP's DNS or a public server like Google or Cloudflare with out a VPN or Tor you might be telling them your IP handle; BIP explicitly encourages help for DNS decision over VPN or Tor because of this.
Pairing this providing with BOLT 12 removes the necessity to run supporting software program that presents a really actual safety concern for unsophisticated customers, and possession of the area alone permits customers to have the whole lot they want. They want a mechanism to hint fee info with a easy human. Readable identifier. BOLT 12 doesn’t require any HTTP servers, handles the precise bill distribution over onion routed connections straight by way of the Lightning Community, and helps OFFER, a static identifier that can be utilized to search out an onion path to that Lightning node. Might be accomplished for. The issue is that the supply is encoded as an enormous seemingly random string like an bill, making it a horrible human readable/usable identifier besides by way of the usage of QR codes or copy and pasting.
By storing a suggestion in a DNS TXT report, to make a fee the person merely must sort somebody's area into their pockets to get the TXT report, get the BOLT 12 supply after which make the fee. They don't have to host any servers or run any software program apart from their Lightning node, the DNS system handles the whole lot for them so far as internet hosting their Bolt 12 providing goes, which Customers can discover them in the event that they wish to pay.
Is that this a totally dependable system? No. Is it any higher than HTTP primarily based methods? Completely. The issue with points like that is that there’s a sure expectation of UX and conduct that most individuals have of their minds as to how digital methods are anticipated to work. With out copying that UX, giant teams of individuals will merely use options that meet that UX expectation. Provided that actuality, in trying to suit Bitcoin into the field of these UX expectations, the design objective must be to satisfy these person wants with the minimal quantity of belief, the minimal quantity of burden on customers, and the minimal quantity of capability. Lack of privateness in new methods. I feel Matt's BIP checks all these bins in comparison with current options.