Matt Corallo proposed just a little greater than every week in the past a BIP for the coordination of creating Bitcoin funds. Making bitcoin funds has at all times introduced one thing of a problem by way of coordination, each on-chain and off-chain with protocols like Lightning, for various causes. In relation to digital programs like e-mail or cost programs like Paypal, Cashapp, and so on. individuals are very used to the idea of a single static identifier. If you wish to ship John an e-mail, you simply e-mail “john@[insert domain].” If you wish to ship John some cash on Cashapp, you simply ship a cost to @John on Cashapp.
That is the consumer expertise that individuals are acquainted with, and on the subject of entrenched consumer conduct and expectations with issues it’s extremely troublesome to push them into a considerable or sharp change of their conduct. Should you current them with a software that requires that, it presents a big diploma of friction and greater than doubtless is just going to disincentivize most individuals from utilizing that software.
On-chain funds run into an issue with this expectation, not due to an incapacity to have a static identifier (a single handle), however due to the privateness implications of posting a single on-chain handle and having everybody you work together with use that to pay you. It places your whole cost historical past and coin possession within the public view of everybody. If you’re solely not often receiving cash once in a while, i.e. when being paid for work or settling bar tabs with folks, it is not a burden in any respect to easily open your pockets and generate a contemporary handle to obtain to. If you’re regularly receiving cash nevertheless, particularly in cases the place you don’t instantly solicit the cost, that presents a severe burden.
That is why instruments like BTCPay Server have been created, with a purpose to decrease the barrier to entry for folks to spin up the wanted infrastructure to automate receiving funds with out doing one thing naive like posting a single handle for everybody paying you to reuse. Nevertheless, this necessitates operating a server that’s continuously obtainable on-line. Whereas the mission has drastically lowered the bar of understanding required, it’s nonetheless a excessive burden for a consumer who merely needs to have the ability to passively obtain cash.
The identical holds true for Lightning besides worse. An bill is barely good for a single cost. Not like an on-chain handle, which may be reused although it’s horrible apply, a Lightning bill can’t be used. As soon as the bill has both been paid or expires the Lightning node in query will deny any try to pay it. This dynamic led to the creation of the LNURL specification, in addition to Lightning Addresses constructed on prime of it. LNURL is a protocol for connecting to an HTTP server by a static IP that may be shared as soon as with a purpose to seize an precise Lightning bill to pay from the server. Constructing on prime of that, Lightning Addresses are a naming scheme on prime of LNURL structured equally to e-mail addresses: John@[domain of LNURL server].
All of those options have downsides. The requirement to run an additional piece of software program (an HTTP server) that is still on-line on a regular basis 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; counting on TLS Certificates Authorities.
Simply Use DNS
HTTP server tooling like LNURL when paired with Lightning Handle use domains to resolve the connection to the HTTP server. Equally BTCPay Servers are all configured with domains quite than utilizing uncooked IP addresses. Matt’s perception is why not simply lower out the dependence on HTTP and use the Area Title System itself?
DNS permits you to affiliate TXT information with a given area identify, creating small human (or machine) readable information that may be queried from DNS servers. Together with Area Title System Safety Extensions (DNSSEC) DNS TXT information present a mechanism that can be utilized with a purpose to question cost info with out the overhead and burden of operating an HTTP server, in addition to supply a bit extra flexibility and openness. DNSSEC offers quite a few instruments for cryptographically signing DNS entries, together with TXT information, with the DNS keys inherent within the hierarchical construction of DNS. This offers a assure that the TXT report you’re querying is the report signed by and distributed to decrease degree DNS servers from the native root server/key.
This will get to the true good thing about DNS as a method for fetching cost information: say goodbye to the requirement of getting to run an HTTP server. A TXT report can encode an on-chain Bitcoin handle (although the BIP particularly recommends AGAINST doing this if you’re not able to commonly rotating new addresses to stop handle reuse), however extra importantly it may additionally comprise a BOLT 12 Lightning Provide.
These information may be fetched from any DNS server, your individual native one, your ISP, even a public server like Google or Cloudflare. From this primary level, one shortcoming of HTTP primarily based options is solved; you’re not leaking your IP handle to the particular person 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’re revealing your IP handle to them; the BIP clearly encourages help for DNS decision over a VPN or Tor for particularly this purpose.
Combining this proposal with BOLT 12 removes the necessity for operating ancillary software program that presents a really actual safety concern for unsophisticated customers, and permits the possession of a website alone to provide customers all the pieces they should have a mechanism to find cost info with a easy human readable identifier. BOLT 12 requires no HTTP server, dealing with the precise bill supply over onion routed connections instantly by the Lightning Community, and helps Provides, a static identifier that can be utilized to search out an onion path to that Lightning node. The issue is the Provide is encoded as a large random seeming string like an bill itself, making it a horrible human readable/usable identifier besides by using QR codes or copy and pasting.
By storing an Provide in a DNS TXT report, all a consumer wants with a purpose to make a cost is somebody’s area to sort into their pockets so it may fetch the TXT report, fetch the BOLT 12 Provide, after which make the cost. They don’t must host any server or run any software program aside from their Lightning node, the DNS system handles all the pieces for them so far as internet hosting their BOLT 12 Provide somebody that customers eager to pay them can discover.
Is that this a superbly trustless system? No. Is it a lot better than HTTP primarily based programs? Completely. The issue with points like that is that there’s a sure expectation of UX and conduct that most individuals have so far as digital programs are speculated to work of their minds. With out replicating that UX, giant teams of individuals will merely use options that do meet that UX expectation. On condition that actuality, in trying to suit Bitcoin into the field of these UX expectations, the design aim ought to be to fulfill these consumer wants with the minimal quantity of belief interjected, the minimal quantity of burden positioned on the customers, and the minimal potential for lack of privateness in new methods. I believe Matt’s BIP checks all of these packing containers as compared with current options.
