Simplifying Bitcoin Addresses DNS – Bitcoin Magazine
This is an opinion editorial by Mark Jeftovic, co-founder 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 that eventually there had 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 properties of Bitcoin, much of the time you will be able to easily claim or verify that a wallet address belongs to a specific entity — think donations to a charity or a crowd fund. 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 ability to resolve IPv6 addresses, but it is also increasingly used to convey metadata about a namespace. Think SRV records, NAPTRs, RBL blocklists, Response Policy Zones (RPZs), and the ubiquitous TXT record (used for SPF, DMARC, DKIM, and anything else that doesn’t naturally fit the protocol).
Along comes Bitcoin and we have the same problem, write big.
The problem specific to Bitcoin and lightning
It appears that much of the payment transaction activity will move to Layer 2 with protocols such as Lightning, and most recently the launch of Lightning Address.
Lightning addresses rely on the LNURL payment protocol and look pretty much like an email address:
via: https://github.com/andrerfneves/lightning-address/blob/master/README.md
The email address nomenclature is the perfect way to convey identity information. It simply delimits organizations and subdivides into units or people within it. Everyone is already used to this format and, as we will see, they have the potential to convey much more information than destination mailboxes.
For years I predicted that this format would become the de facto standard for identity endpoints with Session Initiation Protocol (SIP) and XMPP.
SIP and XMPP didn’t quite take over the world the way I expected them to (at least not yet), and for a while identifiers started to gravitate towards centralized platforms like Twitter handles and Github user IDs. I have always found this quizzical, especially among Bitcoiners.
With Lightning Addresses, we see a way back towards decentralized identifiers, since email addresses themselves are decentralized, within the boundaries of the DNS system itself (more on that below).
There’s just one problem: the LNURL specification as defined lacks an abstraction level. Without it, the range of use for light addresses becomes very limited.
Given the Lightning address:
This means that under the current specification the payment description will be located at:
https://example.com/.velkjent/lnurlp/satoshi/
But what if Satoshi doesn’t have access to the example.com web server? If we stick to the email address analogy: just because you have this as your address does not mean that the server with the matching hostname is where the email is delivered.
In fact, that’s probably not the case more often than it is. For this reason, the MX record type exists in DNS, which adds an additional level of indirection to control the destination of email. They can do email delivery to hostnames operating under a completely different domain name (think of people using an external email provider but with their own custom domain).
The same must happen with Lightning Addresses for much the same reasons. The hostname to the right of the ‘@’ may not have a web server at all, or the user is unnecessarily restricted to using a Lightning address where the hostname component can only be that of the web server hosting the JSON file. It can be a problem when you publish a Lightning address that the user wants to change along the way.
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 prepare the specification for the ENS registry.
I left the meeting thinking that there must be a new DNS resource record, a new record type that will be able to reference blockchain resources from the legacy DNS.
In my mind it would look like an SRV or NAPTR record, which had different fields for protocols, ports and weights (the fact that browsers today still don’t look at SRV records for URLs is one of the big missed opportunities for 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 pointed to and what kind of resource it was.
So in the Lightning GitHub issue, where the LNURL RFC was discussed, someone suggested just adding an address with the “_lud16” subdomain.
Using underscores to separate certain name attributes from actual host names has been around for a while. It was used in the original SRV RR specification RFC2872 and later described as “underline scope” in RFC 8552.
The suggestion immediately exploded in my brain and I realized I had been overthinking this for years.
A scoped label in DNS such as _tcp or _udp is not case sensitive 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 much any valid DNS label, like _lud16 or _btc, gives us a mechanism to limit a response to a query that matches the scope below the parent node of the DNS tree.
Importance:
$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 a response (NXDOMAIN).
A DNS query for type TXT on “_ie.test.example.com” will just return a result for the first record.
A DNS query for type TXT on “test._ie.example.com” will just return the second record.
In other words, we have more TXT records for test.example.com leaf, but we only return the one that was queried with the scoped label, the one that starts with an underscore.
It turns out that this is quite powerful for our purposes. It is also the simplest, optimal solution in our area of use because:
- Anyone can use it.
- It is a format people easily recognize.
- It can be retrofitted to any existing email address via DNS.
- It provides the ability for a json record to exist somewhere other than the server (like how an MX record works).
- Can provide all types of payload.
- Can work across all blockchains.
How Underscore Scoping Can Be Used in Blockchains
Taking the email address format used in Lightning Addresses: , we can use the convention via DNS to specify all types of endpoints for the same identity:
$ORIGIN grenade launcher.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 that’s already in place:
- Programs that already use the LNURL address can always continue to use it
- Apps can add DNS lookups
But DNS is centralized!
It is true that DNS has an inverted tree structure ending at the root “.”. But even that root is fairly decentralized, consisting of thousands of servers operated by at least 13 different operators. The legacy DNS may be logically centralized, but in reality functions more like a kind of decentralized federation.
Even this is changing, developing. I think where we will eventually end up is where namespaces span both the existing inverted tree root and fully decentralized blockchains.
Some of this is already here today: you can use something like Stacks and .btc domains that stick to Bitcoin, and there will likely be other namespaces built directly on top of Bitcoin.
Not all decentralized namespaces have legacy DNS resolvers, but that will change as well. A new DNSresolvers implementation is also being worked on that will resolve Stacks, .btc and HNS domains with Handshake and Unstoppable top-level domains. You can test it via posting to alpha.dnsresolvers.com:
% dig +card easydns.btc @alpha.dnsresolvers.com
3.14.49.122
(This server is proof-of-concept and will disappear in the future, please don’t add it to your resolv.conf.)
All this, and it also solves the fake Twitter handle problem!
Once we make it a convention to use underscore scopes, we find that we can solve all kinds of problems using existing methods.
Let’s look at the fake Twitter handle problem plaguing the Bitcoin space.
The data structure of a Twitter user looks like this:
With underscore, we can assert the true Twitter handle from the hostname in the url element using the following convention:
$ORIGIN grenade launcher.com.
stuntpope._twitter IN TXT «StuntPope»
*._twitter IN TXT “fake”
By itself, this does nothing. No one is going to open a terminal window and type:
“dig -t TXT +short stuntpape._twitter.bombthrower.com”
… to find out about the person sending you a DM, “How’s your trading going today?” is actually me, or one of them legions by StuntPope fraudsters out there on Twitter. (Just kidding of course, no one in their right mind would imitate me. But for many fintwit fixtures this is a real problem.)
But what could happen if this becomes the convention is that developers could build quick and dirty hooks into their apps to make these lookups.
When a fake Twitter profile impersonates someone, they usually 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, the convention is to look up counterfeit Twitter handle on genuine 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 that does just that with three modes:
A) No information claimed;
B) The profile matches the information claimed;
C) The profile does not match the information claimed (it is false).
All this and more can be done using very simple conventions in a ubiquitous protocol that is already deployed.
Conclusion
Wallet addresses lend themselves to needing some sort of naming mechanism. There are several use cases where the need to secure a secure address from an identity comes before pseudonymity or anonymity.
Furthermore, 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 by using DNS, which already underpins the technical infrastructure of the internet, is already a decentralized federation, and is on its way to being anchored on decentralized Layer 1 protocols. We can do that without adding 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 the opinions of BTC Inc Bitcoin Magazine.
