Matt Corallo proposed a little bit greater than per week in the past a BIP for the coordination of constructing Bitcoin funds. Making bitcoin funds has at all times introduced one thing of a problem when it comes to coordination, each on-chain and off-chain with protocols like Lightning, for various causes. In the case of digital programs like e-mail or cost programs like Paypal, Cashapp, and so forth. 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 person expertise that individuals are acquainted with, and in terms of entrenched person habits and expectations with issues it’s extremely tough to push them into a considerable or sharp change of their habits. Should you current them with a device that requires that, it presents a big diploma of friction and greater than possible is solely going to disincentivize most individuals from utilizing that device.
On-chain funds run into an issue with this expectation, not due to an lack of ability to have a static identifier (a single tackle), however due to the privateness implications of posting a single on-chain tackle and having everybody you work together with use that to pay you. It places your total cost historical past and coin possession within the public view of everybody. In case you are solely hardly ever receiving cash every so often, i.e. when being paid for work or settling bar tabs with individuals, it is not a burden in any respect to easily open your pockets and generate a contemporary tackle to obtain to. In case you are continuously receiving cash nevertheless, particularly in cases the place you don’t immediately solicit the cost, that presents a critical burden.
For this reason instruments like BTCPay Server had been created, as a way to decrease the barrier to entry for individuals to spin up the wanted infrastructure to automate receiving funds with out doing one thing naive like posting a single tackle for everybody paying you to reuse. Nonetheless, this necessitates operating a server that’s continually out there on-line. Whereas the undertaking has drastically lowered the bar of understanding required, it’s nonetheless a excessive burden for a person who merely desires 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. In contrast to an on-chain tackle, which might be reused regardless that it’s horrible follow, 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 and 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 via a static IP that may be shared as soon as as a way 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 tackle to the recipient; counting on TLS Certificates Authorities.
Simply Use DNS
HTTP server tooling like LNURL when paired with Lightning Tackle use domains to resolve the connection to the HTTP server. Equally BTCPay Servers are all configured with domains reasonably than utilizing uncooked IP addresses. Matt’s perception is why not simply lower out the dependence on HTTP and use the Area Identify System itself?
DNS permits you to affiliate TXT information with a given area title, creating small human (or machine) readable information that may be queried from DNS servers. Together with Area Identify System Safety Extensions (DNSSEC) DNS TXT information present a mechanism that can be utilized as a way to question cost data with out the overhead and burden of operating an HTTP server, in addition to provide a bit extra flexibility and openness. DNSSEC gives a variety of instruments for cryptographically signing DNS entries, together with TXT information, with the DNS keys inherent within the hierarchical construction of DNS. This gives a assure that the TXT document you’re querying is the document signed by and distributed to decrease stage 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 document can encode an on-chain Bitcoin tackle (although the BIP particularly recommends AGAINST doing this in case you are not able to recurrently rotating new addresses to forestall tackle reuse), however extra importantly it may well additionally include a BOLT 12 Lightning Provide.
These information might be fetched from any DNS server, your personal native one, your ISP, even a public server like Google or Cloudflare. From this primary level, one shortcoming of HTTP based mostly options is solved; you’re not leaking your IP tackle 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 and not using a VPN or Tor you’re revealing your IP tackle 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 every little thing they should have a mechanism to find cost data with a easy human readable identifier. BOLT 12 requires no HTTP server, dealing with the precise bill supply over onion routed connections immediately via 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 an enormous random seeming string like an bill itself, making it a horrible human readable/usable identifier besides via the usage of QR codes or copy and pasting.
By storing an Provide in a DNS TXT document, all a person wants as a way to make a cost is somebody’s area to kind into their pockets so it may well fetch the TXT document, fetch the BOLT 12 Provide, after which make the cost. They don’t have to host any server or run any software program apart from their Lightning node, the DNS system handles every little thing for them so far as internet hosting their BOLT 12 Provide somebody that customers desirous to pay them can discover.
Is that this a superbly trustless system? No. Is it significantly better than HTTP based mostly programs? Completely. The issue with points like that is that there’s a sure expectation of UX and habits that most individuals have so far as digital programs are imagined to work of their minds. With out replicating that UX, giant teams of individuals will merely use alternate options that do meet that UX expectation. Provided that actuality, in making an attempt 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 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 containers as compared with current options.