A Crypto Name System Proposal

I have long been daydreaming of a unified name system for everything crypto. That is, one single namespace for:

  • Address aliases for Bitcoin and altcoins
  • An alternative domain name system (DNS) for the Internet
  • Secure messaging
  • Ticker symbols for crypto stocks and other DeFi assets
  • Whatever else creative souls can think of

I know there are many name systems out there. Namecoin, OpenAlias, Counterparty, Handshake, HNS, ENS and Unstoppable Domains are some that come to mind. I will not discuss these but quickly outline the model I have in mind.

These names are called hash addresses and here are some examples:

  • janssen#v8
  • jp.janssen#xx
  • janssen33#99

The purpose of the hash (#) is to make them recognizable, much like the @ in email addresses. The last two characters serve as an error test, similar to a checksum.

The simplicity of hash addresses is essential. These are meant to be not only human readable, but also easy to remember.

Address Alias
Say that janssen#v8 was registered by 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa. There is a one-to-one relationship between this hash address and this bitcoin address. It can never be changed, nor can another hash address ever be linked to this bitcoin address.

Extended Information
An optional configuration file contains extra information such as DNS info, linked altcoin addresses, etc. I will get to later how this can be secured on the blockchain while keeping the footprint to a minimum.

Free and Open
The complexity of this project is so low that an open source, no funding model should work. The registration of names should be free in the sense that no person or authority will collect fees. Rather some miner fees are inevitable and burning of coins is a necessary anti-spam measure in some cases.

Censorship Resistance
The name system is a 2nd layer on the Bitcoin blockchain. Every registration is recorded on the blockchain and as secure as Bitcoin itself.

Registering a Hash Address
As a general rule, you cannot register janssen#v8 if any other address startsing with janssen# already exists.

Technically the registration is done through the OP_RETURN field in a bitcoin transaction. This can be done either as a dummy transaction where you send some BTC back to yourself (~220 bytes tx) or on top of a regular transaction (<50 bytes added to tx).

Anti Spam Fee
To prevent squatting of short names, a cost must occur. Thankfully this is easy to do in a fair manner. The OP_RETURN field allows adding any amount of bitcoin which then effectively are destroyed. This reduces the total supply of bitcoin and in theory makes every bitcoin holder a little bit richer.

The fee model can be hardcoded something like this:

  • No fee for names of 9 characters and longer
  • 0.0001 BTC (about $3.80) for 8 chars
  • 0.001 BTC ($38) for 7 chars
  • 0.01 BTC ($380) for 6 chars
  • 0.1 BTC ($3800) for 5 chars
  • 1 BTC ($38,000) for 4 chars
  • 10 BTC ($380,000) for 3 chars
  • 100 BTC ($3,800,000) for 2 chars
  • 1000 BTC ($38,000,000) for 1 char

Of course the dollar amount depends on the bitcoin price, but the main objective of preserving short names stays true unless bitcoin truly tanks.

Moving” an Address
Despite the general rule that you cannot register janssen#v8 if any other address starts with janssen#, there is one exception. If you were the one who did register the janssen# address, you (and only you) can register a second janssen# address and assign it to a new bitcoin address. For example you created janssen#v8. Now you can make janssen#45. Note:

  • janssen#v8 stays linked to the original address.
  • janssen#45 must be linked to another address.
  • Only janssen#45 can issue a third janssen#. And so on.

There are a few scenarios where it makes sense to have such a rule:

  • janssen#v8‘s may be protected by 2-3 multisig. One key is lost. They still have 2 keys to set up janssen#45 behind a fresh multisig address. Their customers can be confident the new janssen# is legit as this indeed is a janssen# hash address.
  • nftartist#k1 registers a unique name for each NFT. Therefore he sets up nftartist#k2, nftartist#k3, etc.
  • Sale of name. Although name squatting is a controversial topic, at least those possessing a good name have incentive to protect their name and sell it to someone who may have a good use for it. Note that a 3rd party escrow should be used.

The Global Name Table
To keep track of hash addresses, a script parses the bitcoin blockchain. Every time it finds a valid registration inside an OP_RETURN transaction, it adds it to the name table.

This is similar to how Counterparty and Omni operates. Except much simpler. Once a hash-name-to-bitcoin-address relationship is established, it will never change. Therefore the table is only added to but never modified.

The table size is also very small. Assuming 50 bytes per registration, one can have a million records in a 50 MB table.

A light client does not need to parse the entire blockchain. It is sufficient to keep a local copy of the table. It can verify the authenticity of the table by comparing the file hash with several independent API’s.

Even if the local table is not up to date, nothing bad can happen. The only risk is that a recent hash name is not found. No coins can ever be sent to the wrong address.

Extended Info Table
Above I explained the fundamental table necessary to map hash addresses to bitcoin addresses. Extended info is needed for DNS, tokens, altcoin addresses and everything else.

Such info is added to a text file. The file’s hash is broadcast through OP_RETURN. A second table is updated with these hashes. Unlike the previous table, each record in this table can be updated. This requires clients to stay up to date.

A client must also have access to the actual file. This is rarely a problem as anything on the Internet is propagated in a similar way with no issues.

The advantage with this solution is that all the extended info is censorship proof, and no matter how large this file becomes it only takes up 32 bytes of blockchain space.

Technicalities of Hash Addresses
For the part before the hash (#), the name rules are as follow:

  • minimum length 1 character
  • max 20 chars
  • allowed characters are a-z (lower case), 0-9, and dot (.).
  • a name cannot start or end with a dot
  • two dots in a row are not allowed

Let’s look at the second part (the two characters after the hash) of janssen#v6:

The first character, in this case v, has to be one of only three options. Take the name, janssen, get its sha256 encoded in base64, and find the first lower case letter, first upper case letter and first digit.

The hash of janssen: pVWn4lklCuuYzcLAIi1cMIBoDh6XVoS5n2d+mvG6Vb4

The extracted characters are p, V and 4. One more little rule; convert to lower case, i.e. you are left with p, v and 4.

A bit complex, but for a reason. I don’t want someone to register a similar name with the same validator. Let’s see:

  • jansen: TGF+IE2cG/Ory0Rd86gIyfXBjBhmiynDOZ04lGvDW9g -> t, 2, c
  • jansson: fPQwfT9zgmNUrapT2Km42QQgkYzxqF138h/Kd+PyGkM -> f, p, 9
  • ianssen: utjPycG29ww3CarZGIHNwah7oycap4aEbpEhOYg4LYQ -> u, p, 2

None of these alternative spellings can use v, hence my #v4 validator minimizes the risk of confusing two similar hash names.

The last character is selected by the user. It can be any lower case letter a-z or digit.

Final Notes
I have no plans to pursue this further. I think a project like this needs a lot of backing to gain traction. I just felt like writing down my daydream. I really believe a system like this one, especially with a common standard for messaging and money transfers, would help bring crypto mainstream.

Categories: Uncategorized

Tags: , ,