By now it’s pretty clear that the idea of a _cryptocurrency _probably isn’t going away. It might not be Bitcoin or Litecoin, it might not have the same value as it does today, but the concept of cryptocurrency is here to stay: digital money.
Just like the beginning of IP addresses, using them raw was fine at first. But with crypto, you get long hexadecimal strings that truly no one can remember by heart. It’s far from user friendly.
It’s like trying to remember that 2a03:a800:a1:1952::ff is the address for this site. Doesn’t work very well, does it? It’s far easier to say ma.ttias.be than the cryptic representation of IPv6.
I think we need something similar for cryptocurrencies. Something independent and – relatively – secure. So here’s my proposal I came up with in the car on the way home.
Example: cryptocurrency in DNS
Here’s the simplest example I can give.
$ dig ma.ttias.be TXT | sort ma.ttias.be. 3600 IN TXT "ico:10 btc:1AeCyEczAFPVKkvausLSQWP1jcqkccga9m" ma.ttias.be. 3600 IN TXT "ico:10 ltc:Lh1TUmh2WP4LkCeDTm3kMX1E7NQYSKyMhW" ma.ttias.be. 3600 IN TXT "ico:20 eth:0xE526E2Aecb8B7C77293D0aDf3156262e361BfF0e" ma.ttias.be. 3600 IN TXT "ico:30 xrp:rDsbeomae4FXwgQTJp9Rs64Qg9vDiTCdBv"
Cryptocurrency addresses get published as TXT records to a domain of your choosing. Want to receive a payment? Simple say “send it to ma.ttias.be”, the client will resolve that TXT record and the accompanying addresses and use the priority field as a guideline for choosing which address to pick first.
Think MX records, but implemented as TXT. The lower the priority, the more preferred it is.
The TXT format explained
A TXT format can contain pretty much anything, so it needs some standardization in order for this to work. Here’s my proposal.
ico:[priority] space [currency]:[address]
Let’s pick the first result as an example and tear it down.
$ dig ma.ttias.be TXT | sort | head -n 1 ma.ttias.be. 3600 IN TXT "ico:10 btc:1AeCyEczAFPVKkvausLSQWP1jcqkccga9m"
Translates to;
ico:: a prefix in the TXT record to denote that this ia currency, much like SPF knows the “v=spv1” prefix. This is a fixed value.10: the priority. The lower, the bigger its preference.btc: preferred currency isbtc, or Bitcoin.1AeCyEczAFPVKkvausLSQWP1jcqkccga9m: the btc address to accept payments.
Simple, versatile format.
The priority allows for round robin implementations, if you wish to diversify your portfolio. Adding multiple cryptocurrency allows the sender the freedom to choose which currency he/she prefers, while still honoring your priority.
Technically, I published 2 records with a priority of 10. It’s up to the sender to determine which currency he/she prefers, if it’s available to them. If it isn’t, they can move down the chain & try other addresses published.
It means only addresses on which you want to receive currency should ever be posted as DNS records.
DNSSEC required
To avoid DNS cache poisoning or other man-in-the-middle attacks, DNSSEC would have to be a hard requirement in order to guarantee integrity.
This should not be optional.
If smart people every end up implementing something like this, an additional GPG/PKI like solution might be added for increased security, by signing the addresses once more.
Currency agnostic
This isn’t a solution for Bitcoin, Litecoin or Ripple. It’s a solution for all of them. And all the new currencies to come.
It’s entirely currency agnostic and can be used for any virtual currency.
Multi tenancy
If you want multiple users on the same domain, you could solve this via subdomains. Ie “john.domain.tld”, “mary.domain.tld”, …
It makes the format of the TXT record plain and simple and uses basic DNS records for delegation of accounts.
Why not a dedicated resource record?
For the same reason the SPF resource record went away and was replaced by a TXT alternative: availability.
Every DNS server and client already understands TXT records. If we have to wait for both servers, clients and providers to implement something like a ICO resource record, it’ll take ages. Just look at the current state of CAA records, only a handful of providers offer it, even though it’s a mandatory CA thing already.
There are already simpler naming schemes for cryptocurrency!
Technically, yes, but they all have a deep flaw: you have to trust someone else’s system.
There’s BitAlias, onename, ens for ethereum, okTurtles, … and they all build on top of their own, custom system.
But it turns out, we already have a name-translation-system called DNS, we’d be far better of implementing a readable cryptocurrency variant in DNS than in someone else’s closed system.
The validator regex
With the example given above, it can easily be validated with the following regex.
ico:([0-9]+) ([a-z]{3,}):([a-zA-Z0-9]+)
And it translates to;
- group #1: the priority
- group #2: the currency
- group #3: the address
A complete validator with the dig DNS client would translate to;
$ dig ma.ttias.be TXT | sort | grep -P 'ico:([0-9]+) ([a-z]{3}):([a-zA-Z0-9]+)'
ma.ttias.be. 3600 IN TXT "ico:10 btc:1AeCyEczAFPVKkvausLSQWP1jcqkccga9m"
ma.ttias.be. 3600 IN TXT "ico:10 ltc:Lh1TUmh2WP4LkCeDTm3kMX1E7NQYSKyMhW"
ma.ttias.be. 3600 IN TXT "ico:20 eth:0xE526E2Aecb8B7C77293D0aDf3156262e361BfF0e"
ma.ttias.be. 3600 IN TXT "ico:30 xrp:rDsbeomae4FXwgQTJp9Rs64Qg9vDiTCdBv"
Now, who’s going to make this an RFC? I certainly won’t, I’ve got too many things to do already.