Simplifying Bitcoin Addresses DNS – Bitcoin Magazine
This is an opinion editorial by Mark Jeftovic, cofounder and CEO of easyDNS Technologies Inc. and author of “Managing Mission Critical Domains and DNS.”
From the moment I discovered Bitcoin back in 2013, I knew there would eventually have to be a way to reference wallet addresses using human-readable labels.
The big problem with Bitcoin’s long addresses is that they are not memorable, and despite the pseudonymous or anonymous features of Bitcoin, a lot of the time you want to be able to easily assert or verify that a wallet address belongs to a specific entity — think donations to a charity or a crowdfund. This affects every blockchain.
As a DNS (domain name system) guy, I’ve seen this movie before: DNS was invented to solve the same problem with IPv4 addressing. Over time DNS evolved to do much more — not only did DNS add the capability to resolve IPv6 addresses, but it is also increasingly used to convey metadata about a namespace. Think SRV records, NAPTR’s, RBL blocklists, response policy zones (RPZs) and the ubiquitous TXT record (which is used for SPF, DMARC, DKIM and anything else that doesn’t natively fit the protocol).
Along comes Bitcoin and we have the same problem, writ large.
The Problem Specific To Bitcoin And Lightning
It’s looking like much of the payment transaction activity will move to Layer 2 with protocols like Lightning, and most recently the advent of the Lightning Address.
Lightning Addresses rely on the LNURL-pay protocol, and they look pretty much like an email address:
The email address nomenclature is the perfect way to convey identity information. It easily demarcates organizations and further subdivides to units or people within it. Everybody is already used to this format and as we’ll see, has the potential to convey much more information than destination mailboxes.
For years I was anticipating this format becoming the de facto standard for identity endpoints with Session Initiation Protocol (SIP) and XMPP.
SIP and XMPP didn’t take over the world quite the way I expected them to (at least not yet) and for a while, identifiers started gravitating toward centralized platforms like Twitter handles and Github user IDs. I always found this quizzical, especially among Bitcoiners.
With Lightning Addresses we see a path back toward decentralized identifiers, since email addresses are themselves decentralized, within the limits of the DNS system itself (more on that below).
There’s only one problem: the LNURL spec as defined is missing a level of abstraction. Without it, the use case for Lighting Addresses becomes very constrained.
Given the Lightning Address:
satoshi@example.com
That means under the current specification, the payment descriptor will be located at:
https://example.com/.well-known/lnurlp/satoshi/
But what if Satoshi doesn’t have access to the example.com webserver? If we stick with the email address analogy: just because you have this as your address doesn’t mean the server with the matching hostname is where the email gets delivered.
In fact that’s probably not the case more often than it is. For this reason there exists the MX record type in DNS, which adds an extra level of indirection to control the destination for email. They may direct email delivery to hostnames operating under a completely different domain name (think about people who use an external email provider, but with their own custom domain).
The same thing needs to happen with Lightning Addresses for largely the same reasons. The hostname to the right of the ‘@’ may not have a webserver at all, or the user is unduly confined to using a Lightning Address where the hostname component can only be that of the webserver where the JSON file is hosted. That can be a problem when publishing a Lightning Address that the user wants to change down the road.
As a DNS guy, the solution seemed obvious but I was guilty of overthinking it:
In 2017 I was invited by what was then the Ethereum Name Service Working Group to a meeting in London to work out the specification for the ENS registry.
I left that meeting thinking that there needs to be a new DNS resource record, a new record type that would be able to reference blockchain resources from within the legacy DNS.
In my mind it would look something like a SRV or NAPTR record, which had different fields for protocols, ports and weightings (the fact that web browsers today still don’t look at SRV records for web addresses is one of the great missed opportunities of the internet age).
My working shorthand for it was “BCPTR” for “Blockchain Pointer” and it had an overcomplicated, convoluted specification for pointing out exactly which blockchain a record was pointing at and what type of resource it was.
Then in the Lightning GitHub issue, where the LNURL RFC was being discussed, somebody suggested simply prepending an address with the “_lud16” subdomain.
Using underscores to differentiate certain naming attributes from actual hostnames has been around for awhile. It was used in the original SRV RR spec RFC2872 and later described as “underscore scoping” in RFC 8552.
The suggestion immediately exploded in my brain and I realized that I had been overthinking this for years.
A scoped label in DNS, like _tcp or _udp, are case insensitive and we see them in SRV and NAPTR records for use in SIP, VOIP and ENUM applications, load balancing, not to mention in TXT records for DKIM and DomainKeys.
Pretty well any valid DNS label, like _lud16 or _btc, provides us with a mechanism to confine a response to a query matching the scope, under the parent node in the DNS tree.
Meaning:
$ORIGIN example.com.
_ie.test IN TXT “this is a test”_eg.test IN TXT “this is a separate test”
A DNS query for type TXT on “test.example.com” will not return an answer (NXDOMAIN).
A DNS query for type TXT on “_ie.test.example.com” will only return a result for the first record.
A DNS query for type TXT on “test._ie.example.com” will only return the second record.
In other words, we have multiple TXT records for the test.example.com leaf, however, we will only return the one queried with the scoped label, the one that begins with an underscore.
It turns out this is quite powerful for our purposes. It is also the easiest, optimal solution in our use case because:
- Everybody can use it.
- It’s a format people easily recognize.
- It can be retrofitted onto any existing email address via DNS.
- It provides the ability for a json record to exist someplace other than the server (like how an MX record functions).
- Can provide any kind of payload.
- Can work across all blockchains.
How Underscore Scoping Could Be Used In Blockchains
By taking the email address format used in Lightning Addresses: , we can use the convention via the DNS to specify all kinds of endpoints for the same identity:
$ORIGIN bombthrower.com.
_lud16.markjr IN TXT “https://my.ln-node/.well-known/lnurlp/markjr”
_btc.markjr IN TXT “bc1qu059yx6ygg9e6tgedktlsndm56jrckyf3waszl”
_ens.markjr IN TXT “0xEbE7CcC5A0D656AD3A153AFA3d543160B2E9EdFb”
We can get there from here without breaking anything already in place:
- Applications already using LNURL address can always keep using that
- Applications can add the DNS lookup
But DNS Is Centralized!
It’s true that DNS has an inverted tree structure that terminates at the root “.”. But even that root is fairly decentralized, comprising thousands of servers operated by at least 13 disparate operators. The legacy DNS may be logically centralized but in reality functions more like a decentralized federation of sorts.
Even this is changing, evolving. I think where we eventually end up is where namespaces straddle both the existing inverted tree root and fully decentralized blockchains.
Some of this is already here today: you could use something like Stacks and .btc domains which pins to Bitcoin and there will probably be other namespaces built directly atop Bitcoin.
Not all decentralized namespaces have legacy DNS resolvers, but that will change too. There is also work being done on a new DNSresolvers implementation which will resolve Stacks, .btc, and HNS domains by Handshake, and Unstoppable top-level domains. You can test it via lookups to alpha.dnsresolvers.com:
% dig +short easydns.btc @alpha.dnsresolvers.com
3.14.49.122
(This server is proof-of-concept and will go away in the future, please don’t add it to your resolv.conf.)
All This, And It Solves The Fake Twitter Handle Problem Too!
Once we make it a convention to use underscore scoping, we find we can solve all manner of problems using existing methods.
Let’s look at the fake Twitter handle problem that plagues the Bitcoin space.
The data structure of a Twitter user looks like this:
With underscore scoping we can assert the true Twitter handle from the hostname in the url element using the following convention:
$ORIGIN bombthrower.com.
stuntpope._twitter IN TXT “StuntPope”
*._twitter IN TXT “fake”
On its own, this doesn’t do anything. Nobody is going to open up a terminal window and type:
“dig -t TXT +short stuntpope._twitter.bombthrower.com”
… to find out if the person DMing you, “How is your trading going today?” is really me, or one of the legions of StuntPope imposters out there on Twitter. (I’m kidding of course, nobody in their right mind would impersonate me. But for a lot of the fintwit luminaries, this is a real problem.)
But what can happen if this becomes the convention, is developers can build quick and dirty hooks into their apps to do these lookups.
When a fake Twitter profile impersonates someone, they typically copy all the data verbatim, including the hostname in the URL field of the Twitter profile. If the real user has the records outlined above, then the convention of looking up the fake Twitter handle at the real URL will miss the actual _twitter TXT record for the real profile, and hit the wildcard record, causing a mismatch.
We’ve released a proof-of-concept Chrome extension through the easyDNS Github, which does just that with three modes:
A) No information asserted;
B) The profile matches the information asserted;
C) The profile does not match the information asserted (it’s a fake).
All this and more, can be done using very simple conventions in a ubiquitous protocol that’s already deployed.
Conclusion
Wallet addresses lend themselves to needing some kind of naming mechanism. There are multiple use cases where the need to securely assert an address from an identity takes precedence over pseudonymity or anonymity.
Further, to use human-readable labels or identifiers, we need an abstraction layer that provides flexibility and a format that is easily recognizable.
Finally, we can achieve all this using the DNS, which already underpins the technical infrastructure of the internet, is already a decentralized federation and on its way to anchoring on decentralized Layer 1 protocols. We can do so without adding any new record types or making any protocol additions to the existing specifications.
This is a guest post by Mark Jeftovic. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
Credit: Source link
Comments are closed.