Simplifying Bitcoin Addresses DNS – Bitcoin Magazine


That is an opinion editorial by Mark Jeftovic, cofounder and CEO of easyDNS Applied sciences Inc. and creator of “Managing Mission Vital Domains and DNS.”

From the second I found Bitcoin again in 2013, I knew there would ultimately should be a option to reference pockets addresses utilizing human-readable labels.

The large downside with Bitcoin’s lengthy addresses is that they don’t seem to be memorable, and regardless of the pseudonymous or nameless options of Bitcoin, lots of the time you need to have the ability to simply assert or confirm {that a} pockets handle belongs to a selected entity — assume donations to a charity or a crowdfund. This impacts each blockchain.

As a DNS (area title system) man, I’ve seen this film earlier than: DNS was invented to unravel the identical downside with IPv4 addressing. Over time DNS developed to do way more — not solely did DNS add the aptitude to resolve IPv6 addresses, however it is usually more and more used to convey metadata a few namespace. Suppose SRV data, NAPTR’s, RBL blocklists, response coverage zones (RPZs) and the ever-present TXT file (which is used for SPF, DMARC, DKIM and anything that doesn’t natively match the protocol).

Alongside comes Bitcoin and we have now the identical downside, writ giant.

The Drawback Particular To Bitcoin And Lightning

It’s wanting like a lot of the fee transaction exercise will transfer to Layer 2 with protocols like Lightning, and most lately the arrival of the Lightning Handle.

Lightning Addresses depend on the LNURL-pay protocol, and so they look just about like an e mail handle:

the lightning address satoshi domain

by way of:

The e-mail handle nomenclature is the right option to convey identification data. It simply demarcates organizations and additional subdivides to models or folks inside it. All people is already used to this format and as we’ll see, has the potential to convey way more data than vacation spot mailboxes.

For years I used to be anticipating this format changing into the de facto normal for identification endpoints with Session Initiation Protocol (SIP) and XMPP.

SIP and XMPP didn’t take over the world fairly the way in which I anticipated them to (a minimum of not but) and for some time, identifiers began gravitating towards centralized platforms like Twitter handles and Github consumer IDs. I all the time discovered this quizzical, particularly amongst Bitcoiners.

With Lightning Addresses we see a path again towards decentralized identifiers, since e mail addresses are themselves decentralized, throughout the limits of the DNS system itself (extra on that beneath).

There’s just one downside: the LNURL spec as outlined is lacking a degree of abstraction. With out it, the use case for Lighting Addresses turns into very constrained.

Given the Lightning Handle:

[email protected]

Meaning underneath the present specification, the fee descriptor will probably be situated at:

However what if Satoshi doesn’t have entry to the webserver? If we persist with the e-mail handle analogy: simply because you might have this as your handle doesn’t imply the server with the matching hostname is the place the e-mail will get delivered.

In truth that’s in all probability not the case extra usually than it’s. For that reason there exists the MX file kind in DNS, which provides an additional degree of indirection to manage the vacation spot for e mail. They could direct e mail supply to hostnames working underneath a totally totally different area title (take into consideration individuals who use an exterior e mail supplier, however with their very own customized area).

The identical factor must occur with Lightning Addresses for largely the identical causes. The hostname to the fitting of the ‘@’ could not have a webserver in any respect, or the consumer is unduly confined to utilizing a Lightning Handle the place the hostname part can solely be that of the webserver the place the JSON file is hosted. That may be an issue when publishing a Lightning Handle that the consumer desires to alter down the street.

As a DNS man, the answer appeared apparent however I used to be responsible of overthinking it:

In 2017 I used to be invited by what was then the Ethereum Identify Service Working Group to a gathering in London to work out the specification for the ENS registry.

I left that assembly pondering that there must be a brand new DNS useful resource file, a brand new file kind that will be capable to reference blockchain sources from throughout the legacy DNS.

In my thoughts it will look one thing like a SRV or NAPTR file, which had totally different fields for protocols, ports and weightings (the truth that internet browsers as we speak nonetheless don’t have a look at SRV data for internet addresses is likely one of the nice missed alternatives of the web age).

My working shorthand for it was “BCPTR” for “Blockchain Pointer” and it had an overcomplicated, convoluted specification for mentioning precisely which blockchain a file was pointing at and what kind of useful resource it was.

Then within the Lightning GitHub problem, the place the LNURL RFC was being mentioned, anyone advised merely prepending an handle with the “_lud16” subdomain.

Utilizing underscores to distinguish sure naming attributes from precise hostnames has been round for awhile. It was used within the unique SRV RR spec RFC2872 and later described as “underscore scoping” in RFC 8552.

The suggestion instantly exploded in my mind and I noticed 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 data to be used in SIP, VOIP and ENUM purposes, load balancing, to not point out in TXT data for DKIM and DomainKeys.

Fairly effectively any legitimate DNS label, like _lud16 or _btc, supplies us with a mechanism to restrict a response to a question matching the scope, underneath the dad or mum node within the DNS tree.

Which means:

$ORIGIN a look at IN TXT “this can be a take a look at”

_eg.take a look at IN TXT “this can be a separate take a look at”

A DNS question for kind TXT on “take a look” is not going to return a solution (NXDOMAIN).

A DNS question for kind TXT on “_ie.take a look” will solely return a outcome for the primary file.

A DNS question for kind TXT on “take a look” will solely return the second file.

In different phrases, we have now a number of TXT data for the take a look leaf, nevertheless, we are going to solely return the one queried with the scoped label, the one which begins with an underscore.

It seems that is fairly highly effective for our functions. It’s also the best, optimum resolution in our use case as a result of:

All people can use it.
It’s a format folks simply acknowledge.
It may be retrofitted onto any current e mail handle by way of DNS.
It supplies the flexibility for a json file to exist someplace apart from the server (like how an MX file capabilities).
Can present any form of payload.
Can work throughout all blockchains.

How Underscore Scoping Might Be Used In Blockchains

By taking the e-mail handle format utilized in Lightning Addresses: , we will use the conference by way of the DNS to specify every kind of endpoints for a similar identification:

$ORIGIN IN TXT “https://my.ln-node/.well-known/lnurlp/markjr”_btc.markjr IN TXT “bc1qu059yx6ygg9e6tgedktlsndm56jrckyf3waszl”_ens.markjr IN TXT “0xEbE7CcC5A0D656AD3A153AFA3d543160B2E9EdFb”

We will get there from right here with out breaking something already in place:

Functions already utilizing LNURL handle can all the time preserve utilizing that
Functions can add the DNS lookup

However DNS Is Centralized!

It’s true that DNS has an inverted tree construction that terminates on the root “.”. However even that root is pretty decentralized, comprising hundreds of servers operated by a minimum of 13 disparate operators. The legacy DNS could also be logically centralized however in actuality capabilities extra like a decentralized federation of types.

Even that is altering, evolving. I believe the place we ultimately find yourself is the place namespaces straddle each the present inverted tree root and totally decentralized blockchains.

A few of that is already right here as we speak: you possibly can use one thing like Stacks and .btc domains which pins to Bitcoin and there’ll in all probability be different namespaces constructed instantly atop Bitcoin.

Not all decentralized namespaces have legacy DNS resolvers, however that can change too. There’s additionally work being carried out on a brand new DNSresolvers implementation which can resolve Stacks, .btc, and HNS domains by Handshake, and Unstoppable top-level domains. You possibly can take a look at it by way of lookups to

% dig +quick easydns.btc

(This server is proof-of-concept and can go away sooner or later, please don’t add it to your resolv.conf.)

All This, And It Solves The Faux Twitter Deal with Drawback Too!

As soon as we make it a conference to make use of underscore scoping, we discover we will remedy all method of issues utilizing current strategies.

Let’s have a look at the pretend Twitter deal with downside that plagues the Bitcoin house.

The info construction of a Twitter consumer appears like this:

structure of twitter user data

With underscore scoping we will assert the true Twitter deal with from the hostname within the url ingredient utilizing the next conference:


stuntpope._twitter IN TXT “StuntPope”

*._twitter IN TXT “pretend”

By itself, this doesn’t do something. No one goes to open up a terminal window and sort:

“dig -t TXT +quick”

… to search out out if the individual DMing you, “How is your buying and selling going as we speak?” is absolutely me, or one of many legions of StuntPope imposters on the market on Twitter. (I’m kidding in fact, no one of their proper thoughts would impersonate me. However for lots of the fintwit luminaries, this can be a actual downside.)

However what can occur if this turns into the conference, is builders can construct fast and soiled hooks into their apps to do these lookups.

When a pretend Twitter profile impersonates somebody, they usually copy all the info verbatim, together with the hostname within the URL subject of the Twitter profile. If the true consumer has the data outlined above, then the conference of wanting up the pretend Twitter deal with on the actual URL will miss the precise _twitter TXT file for the true profile, and hit the wildcard file, inflicting a mismatch.

twitter chicken with a bar through face

We’ve launched a proof-of-concept Chrome extension via the easyDNS Github, which does simply that with three modes:

A) No data asserted;

B) The profile matches the knowledge asserted;

C) The profile doesn’t match the knowledge asserted (it’s a pretend).

All this and extra, might be carried out utilizing quite simple conventions in a ubiquitous protocol that’s already deployed.

twitter proof of verification easy API use


Pockets addresses lend themselves to needing some form of naming mechanism. There are a number of use circumstances the place the necessity to securely assert an handle from an identification takes priority over pseudonymity or anonymity.

Additional, to make use of human-readable labels or identifiers, we want an abstraction layer that gives flexibility and a format that’s simply recognizable.

Lastly, we will obtain all this utilizing the DNS, which already underpins the technical infrastructure of the web, is already a decentralized federation and on its option to anchoring on decentralized Layer 1 protocols. We will achieve this with out including any new file sorts or making any protocol additions to the present specs.

It is a visitor publish by Mark Jeftovic. Opinions expressed are fully their very own and don’t essentially replicate these of BTC Inc or Bitcoin Journal.


Leave A Reply

Your email address will not be published.