Sending a cryptocurrency transaction requires a long, human-hostile sequence of characters By pointing a human-readable name at the address, users can send cryptocurrency to the name instead of needing to ask for an address. This enables a more user-friendly experience, improved security and enables additional functionality such as automated-recurring transactions. In this document, we propose a standard for global name systems that map names to addresses.
Sending a cryptocurrency transaction to another requires knowing the preferred address (or account) of the recipient. This is typically is a long, human-hostile sequence of letters and numbers which is inconvenient to type and error-prone to verify. A single mis-typed character can make the address invalid requiring the user to re-type it or at worse result in loss of funds.
By pointing a human-readable name at the account or address enable, users can send cryptocurrency directly to the name instead of needing to ask for an address enabling a much more user-friendly experience. In addition, when this name-address mapping is stored in a name system that supports cryptographic authentication, the user can also be sure that the address a query returns was entered by the person in control of the name.
A donor wishing to donate BTC to the Bitcoin Association of Hong Kong has to locate the donation address on bitcoin.org.hk , 1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS, and then copy and paste or type it into his wallet before sending the donation. With this standard and wallet support, the user could enter bitcoin.org.hk in his wallet and send bitcoin directly to the appropriate address.
The previous donor might want to make a monthly BTC donation to the Bitcoin Association of Hong Kong. To do this, he would have to look up the current address for the association each month or the association would have to commit to never changing the address. The association might not want to make that commitment because The association, however, might not want to make such a commitment because changing the address has a number of potential benefits. It might enable support a new address format bringing possibly lower fees, more functionality or improved security. Changing the address might reflect a new multi-sig wallet generated to reflect a change in board membership.
Instead, with this standard, he could authorize his wallet to periodically send cryptocurrency to bitcoin.org.hk and his wallet could figure out the appropriate address at which the association wishes to receive donations on his behalf.
An address refers to the public key representation of an cryptocurrency key pairs in a format commonly presented to end users. In some cryptocurrencies, address is referred to as an account. Users of this protocol MAY use either term, but this specification will use the term “address” to refer to both.
NS refers to a globally accessible key-value Name System. This standard works best with name systems that support a subset of the zone file standard as defined in RFC1034 and RFC1035.
Examples include but are not limited to:
- BNS - the Bitcoin Name System - anchored in Bitcoin with smart contract logic on the Stacks blockchain
- DNS - the Domain Name System - run by the corporation ICANN
- ENS - the Ethereum Name System - built on Ethereum
- HNS - the Handshake Name System - built on Handshake
A binding using NS TXT RRs as an address or account service is hereby defined. All implementations MUST support this binding.
All addresses or accounts are stored in an underscored attribute leaf named _addr. prepended with coin’s ticker symbol name. The resource record name for the BTC address of DNS domain example.com would be _btc._addr.example.com.
The DNS Resource Record type used is specified by an option to the
query-type ("q=") tag. The only option defined in this base standard is "txt", indicating the use of a TXT RR. A later extension of this standard may define another RR type. Strings in a TXT RR MUST be concatenated together before use with no intervening whitespace. TXT RRs MUST be unique for a particular selector name; (eg. only one _btc._addr.example.com). If there are multiple records in an RRset, the results are undefined. TXT RRs are encoded as described in Section 3.3
Addresses are stored as a comma-delimited list. The first address in the list is the default address and MUST be presented as the default or preferred address in applications that permit multiple address to displayed. Trailing commas
_btc._addr.bitcoin.org.hk. IN TXT "1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS"
DNS name bitcoin.org.hk resolves to BTC address 1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS
resolveName("bitcoin.org.hk).getDefaultAddress("BTC") // returns { coin: "BTC", address:"1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS" }
resolveName("bitcoin.org.hk).getAddresses("BTC") // returns [{ coin: "BTC", address:"1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS" }]
resolveName("bitcoin.org.hk).getDefaultAddress("STX") // returns null
resolveName("bitcoin.org.hk).getAddresses("STX") // returns null_btc._addr.muneeb.btc. IN TXT "1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS"
BNS name muneeb.btc owned by SP132QXWFJ11WWXPW4JBTM9FP6XE8MZWB8AF206FX resolves to BTC address 1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS.
resolveName("muneeb.btc").getDefaultAddress("BTC") // returns { coin: "BTC", address:"1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS" }
resolveName("muneeb.btc").getAddresses("BTC") // returns [{ coin: "BTC", address:"1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS" }]
resolveName("bitcoin.org.hk).getDefaultAddress("STX") // returns { coin: "STX", address:"SP132QXWFJ11WWXPW4JBTM9FP6XE8MZWB8AF206FX" }
resolveName("bitcoin.org.hk).getAddresses("STX") // returns [{ coin: "STX", address:"SP132QXWFJ11WWXPW4JBTM9FP6XE8MZWB8AF206FX" }]_btc._addr.example.com. IN TXT "1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS,1111111111111111111114oLvT2"
DNS name example.com resolves to the BTC addresses 1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS and 1111111111111111111114oLvT2. The default BTC address is 1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS.
resolveName("example.com").getDefaultAddress("BTC"); // returns { coin: "BTC", address:"1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS" }
resolveName("example.com").getAddresses("BTC"); // returns [{ coin: "BTC", address:"1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS" },{ coin: "BTC", address:"1111111111111111111114oLvT2" }]
resolveName("example.com").getDefaultAddress("STX"); // returns null_btc._addr.muneeb.btc. IN TXT "1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS"
_stx._addr.muneeb.btc. IN TXT "SP000000000000000000002Q6VF78"
BNS name muneeb.btc resolves to the BTC address 1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS and the STX address SP000000000000000000002Q6VF78.
resolveName("muneeb.btc").getDefaultAddress("BTC"); // returns { coin: "BTC", address:"1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS" }
resolveName("muneeb.btc").getAddresses(); // returns [{ coin: "BTC", address:"1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS" },{ coin: "STX", address:"SP000000000000000000002Q6VF78" }]
resolveName("muneeb.btc").getDefaultAddress("STX"); // returns { coin: "STX", address:"SP000000000000000000002Q6VF78" }The intent of this standard is to result in a set of tools and applications that can work across multiple name systems. This section currently lists name system attributes that may have bearing on the interaction of this standard with the system.
- Zone file support
- Built-in cryptographic authentication
- BTC/STX coin types can default to the owner of the name
- Full zone file support
- DNSSEC provides a degree of cryptographic authentication
- No default address
- Generally, does not support zone files. Possible to adapt to standard to txt type.
- Built-in cryptographic authentication
- ETH coin types can default to owner of the name
- Zone file support
- Built-in cryptographic authentication of TLD, unclear about the cryptographic guarantees for subdomains of TLDs
- HNS coin types can default to owner of the name
Addresses for layer 2 payment networks such as the Lightning Network use different address formats than used by the underlying coin. It is important that they be integrated into this standard. A couple approaches come to mind which are outlined below for completeness and as a jumping off point for further research and discussion.
An underscored attribute leaf node specific to the layer 2 network could be prepended to the existing attribute record name and be used to store the ligthning address.
_ln._btc._addr.larry.btc. IN TXT "larry@bitcoin.org.hk"
Layer 2 payment network addresses could be directly stored in the attribute resource record defined in this standard and associated tooling (or wallets) could be responsible for recognizing the type of address.
_btc._addr.larry.btc. IN TXT "larry@bitcoin.org.hk"
There is a line of reason that says tokens on a layer 2 payment network are not the same tokens as those on the layer 1 network because they have different functionality and risk characteristics. It is possible to treat tokens on another layer such as bitcoins on the Lightning Networks a different coin with respect to this standard and differentiate by attribute names.
_lnbtc._addr.larry.btc. IN TXT "larry@bitcoin.org.hk"
_btc._addr.larry.btc. IN TXT "1BAHK1Esvn6L1icZREB8SFqTy7bBSRDwaS"