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 many others. 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 accustomed to, and in relation to entrenched person conduct and expectations with issues it’s extremely troublesome to push them into a considerable or sharp change of their conduct. For those who current them with a software that requires that, it presents a big diploma of friction and greater than doubtless is solely 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 hardly ever receiving cash from time to time, 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 recent handle to obtain to. If you’re steadily receiving cash nevertheless, particularly in cases the place you don’t instantly solicit the cost, that presents a critical burden.
That is why instruments like BTCPay Server had been created, so as 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. Nonetheless, this necessitates operating a server that’s always 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 needs to have the ability to passively obtain cash.
The identical holds true for Lightning besides worse. An bill is just good for a single cost. In contrast to an on-chain handle, which could be reused although 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 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 so as 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 Tackle use domains to resolve the connection to the HTTP server. Equally BTCPay Servers are all configured with domains fairly than utilizing uncooked IP addresses. Matt’s perception is why not simply reduce out the dependence on HTTP and use the Area Title System itself?
DNS permits you to affiliate TXT data with a given area title, creating small human (or machine) readable data that may be queried from DNS servers. Together with Area Title System Safety Extensions (DNSSEC) DNS TXT data present a mechanism that can be utilized so as 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 supplies quite a lot of instruments for cryptographically signing DNS entries, together with TXT data, with the DNS keys inherent within the hierarchical construction of DNS. This supplies a assure that the TXT document you might be querying is the document 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 document can encode an on-chain Bitcoin handle (although the BIP particularly recommends AGAINST doing this if you’re not able to often rotating new addresses to stop handle reuse), however extra importantly it could actually additionally include a BOLT 12 Lightning Supply.
These data could be fetched from any DNS server, your individual native one, your ISP, even a public server like Google or Cloudflare. From this fundamental level, one shortcoming of HTTP primarily based options is solved; you might be 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 no VPN or Tor you might be revealing your IP handle to them; the BIP clearly encourages assist for DNS decision over a VPN or Tor for particularly this cause.
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 present customers every 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 instantly by the Lightning Community, and helps Gives, a static identifier that can be utilized to seek out an onion path to that Lightning node. The issue is the Supply is encoded as a large random seeming string like an bill itself, making it a horrible human readable/usable identifier besides by the usage of QR codes or copy and pasting.
By storing an Supply in a DNS TXT document, all a person wants so as to make a cost is somebody’s area to sort into their pockets so it could actually fetch the TXT document, fetch the BOLT 12 Supply, 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 thing for them so far as internet hosting their BOLT 12 Supply somebody that customers eager to pay them can discover.
Is that this a wonderfully 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 presupposed 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 making an attempt to suit Bitcoin into the field of these UX expectations, the design objective must be to fulfill 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 packing containers compared with present options.
