Standardizing names for Bitcoin addresses

Alice wants to send 1 bitcoin to Bob. She doesn’t care which address she sends it to as long as it’s the address Bob wants. Alice certainly hasn’t memorized Bob’s bitcoin address so she has to ask Bob for the address who has to look it up in his wallet before sending it to her. It's a hassle for both of them. It would be much easier if she could simply send the bitcoin to Bob’s name, which she already knows.

There have been many attempts over the years to map names to bitcoin addresses and other cryptocurrency addresses. Most recently, developers and users of the Bitcoin Name System (BNS) have asked for support for this in a future of update of the system. It turns out, we don’t need to wait for an update to BNS to create this functionality. We can already create this mapping today in BNS by using the update-name method and storing the mapping in the attached zone file. And because BNS was built with compatibility with DNS in mind, the same technique can be used with DNS and other name system such as HNS that also share DNS zone file compatibility.

In this post, I will outline how we can perform this mapping using what we have today. For more details, you can read the draft standard. But first, a brief review of naming system architecture.

A brief review of BNS & DNS architecture

DNS and BNS can both be thought of as key-value stores. Both DNS names and BNS names are one-way pointers to a text file called a zone file. The name is the key and the value is the zone file. Zone files can also be thought of as their own key-value stores. Each specially formatted text file contains a list of named resource records (“RR”) which in turn point to their own values. Historical RFCs, documents that describe internet standards and protocols, define various types of resource records and the types of data that they should store. Some like A and AAAA records are very specific as to which data is allowable - IP addresses only - and others like TXT and SRV provide wide latitude for developers to store arbitrary data. This ability to store arbitrary data gives application developers the ability to build new functionality and develop conventions without requiring a network-wide upgrade or top-down standards body coordination.

For BNS, which was built from the outset with support for DNS-compatible zone files, this means we can add name-address (or account!) mapping support without requiring any changed or new smart contracts. Wallet and application developers that are interested in supporting this use case can use the standard and those that don’t care about it or disagree with it can ignore it.

Adding addresses and accounts as TXT RRs

TXT RRs and their support for arbitrary text data are the obvious candidate for storing Bitcoin addresses and other cryptocurrency accounts since they too are just strings of ascii characters.

To understand how we can store addresses for different cryptocurrencies, we first need to learn about underscored attribute leaf records. These are essentially subdomains of a name that start with the underscore character, “_,”, a character which is not allowed in the registration of names of either system. The records are intended to be used to store…you guessed it…attributes associated with the name off-which they leaf.

We can designate a specific attribute for each cryptocurrency and store the associated account in it. To be more specific,I propose that we store addresses and accounts for cryptocurrencies in an underscored leaf record of _addr prepended with an underscored leaf record of the ticker symbol of the currency. For a bitcoin address, this the TXT RR name would be _btc._addr.

For example, the Bitcoin Association of Hong Kong could associate its donation address, 1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS, with its DNS domain bitcoin.org.hk by creating a TXT record with the name _btc._addr.bitcoin.org.hk and storing the address in it.

The DNS zone file entry for would look like this:

_btc._addr.bitcoin.org.hk.   IN   TXT   "1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS"

If I wanted all money sent to my BNS name, larry.btc , to be donated to the association, I could also map my name to same bitcoin address by creating the TXT record _btc._addr.larry.btc in larry.btc’s zone file.

The BNS zone file record entry for my name would look like this:

_btc._addr.larry.btc.   IN   TXT   "1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS"

We can also design the standard so that it has support for default addresses which exist on BNS and other blockchain-based name systems and provide a mechanism for multiple addresses or accounts to be associated with a single name.

How this might look for app developers

For app developers, looking up the address should be as simple as resolving the name and calling a function to get either the default address or a list of all the addresses that they're interested in. Tooling would be responsibile for verifying authenticity of the name-address mapping to the limits of the underlying name system.

What’s next

I created this draft standard in the hope that it will provide a place to start for the BNS community that’s interested in being able to send bitcoin, tokens, NFTs and other assets to names instead of addresses and accounts. By creating something that is name system agnostic, I hope that we can we avoid duplication of effort and that tools are built that can easily work with not only BNS but also DNS, HNS and other name systems that are compatible with DNS zone files.

The next step is for feedback from both the community and wallet and other applications developers.

Please leave your comments and thoughts on the thread in the Stacks forum or tweet at me.

Thanks to Ken Liao of Xverse for his comments and feedback on the draft standard and to Mark E. Jeftovic of easyDNS Technologies for his excellent article in Bitcoin Magazine.