BurnDNS is a proposal for an efficient decentralized DNS system based on burning bitcoins. It emphasizes ease of implementation and the ability work with SPV clients.
In BurnDNS, anyone can register a new DNS entry by burning (i.e. destroying) bitcoins. Each time you burn bitcoins, you include a mapping from domain name to address. It's possible for one domain name to map to multiple addresses; in this cases, the addresses should be tried in order of the amount of bitcoins burned.
BurnDNS is simple because it uses only the Bitcoin blockchain; there is no other network required for BurnDNS to function. BurnDNS software can be implemented on top of existing Bitcoin libraries.
It's practical because it can be used with simplified payment verification (SPV) clients. This means that a BurnDNS client only ever downloads block headers and relevant transactions. This uses over 10,000 times less bandwidth than downloading the whole blockchain.
BurnDNS domains should be written out using the .burn pseudo-TLD, e.g. google.burn.
A BurnDNS transaction is a special Bitcoin transaction. It must include an "indexing output" for efficiently locating the transaction and one or more "data outputs" that specify the mapping from domain name to address. It may include any number of additional arbitrary outputs, such as a change payment.
A BurnDNS transaction may include arbitrary inputs.
The purpose of the indexing output is to efficiently indicate that a transaction is for BurnDNS; other than that, it doesn't contain any data. The indexing output must be a pay-to-pubkey-hash script that is sent to the obviously unspendable address 1BurnDNSXXXXXXXXXXXXXXXXXXXXWNhumv. This output will let the transaction be picked up by SPV clients by using a BIP 37 Bloom filter.
The purpose of a data output is to map from a BurnDNS domain name to an address. It is an OP_RETURN output.
- Four BurnDNS prefix bytes,
0x0001f525that indicate that the output is a BurnDNS transaction. - A procotol version indicator byte,
0x00. - The domain name to map from, not including the
.burnsuffix. This follows follow the same validity rules as a normal domain name. - A delimiter byte,
0x00. - The address to map to. This could be an ASCII-encoded IP address or a normal domain name.
Here is an example script that maps google.burn to bing.com (kekeke).
Purpose Hex Unicode
----------------- --- -------
OP_RETURN 6a
OP_PUSHDATA_20 14
BurnDNS prefix 00 🔥
BurnDNS prefix 01 .
BurnDNS prefix f5 .
BurnDNS prefix 25 .
Protocol version 00
Map from 67 g
Map from 6f o
Map from 6f o
Map from 67 g
Map from 6c l
Map from 65 e
Delimit key/value 00
Map to 62 b
Map to 69 i
Map to 6e n
Map to 67 g
Map to 2e .
Map to 63 c
Map to 6f o
Map to 6c m
The funds sent to 1BurnDNSXXXXXXXXXXXXXXXXXXXXWNhumv in a transaction should be applied proportionally to each BurnDNS output with protocol version 0 in that transaction.
All of the funds for a particular mapping should be added. For example, two transactions each applying 0.01 BTC for the mapping google.burn -> google.com should result in a mapping strength of 0.02 BTC from google.burn to google.com.
It may be wise for clients to wait before applying funds to a DNS address. For example, if funds were applied in a linearly increasing function increasing up to 48 hours, this would give site owners time to respond to a takeover. This would not increase the time required to register a new domain, but it would increase the time required to change an existing domain.
100% + X X X ...
| X
50% + X
| X
0% X----+----+----+----+----+----+ ...
0h 12h 24h 36h 48h 60h 72h
At the heart of proof of burn is the idea that users must sacrifice bitcoins. If this seems wasteful, remember that provable destruction of resources is the same basic principle behind Bitcoin.
As part of the destruction, it must be obvious that the burned bitcoins are intended for a particular purpose, and that they cannot ever be spent again. You're not really sacrificing the bitcoins if they can be used for multiple purposes, or if you can later spend them.
In an indexing output, the coins cannot ever be spent because that would require reversing the hash of 1BurnDNSXXXXXXXXXXXXXXXXXXXXWNhumv, then finding a matching private key for the resulting public key. The coins are clearly intended only for BurnDNS because this unspendable address is specific to BurnDNS.
In a data output, the coins cannot ever be spent because a data output is an OP_RETURN output, whcih is by definition unspendable. The coins are clearly intended only for BurnDNS because the transaction must be prefixed with the BurnDNS prefix.
If the price of Bitcoin drops, it will become easier to overwrite a BurnDNS entry, and vice versa. An ideal DNS system would be insulated from these fluctuations, but this is currently an unsolved problem. Users of BurnDNS may wish to hedge against this risk by maintaining a reserve of bitcoins.
A wealthy "bad guy" could take over a site by replacing the BurnDNS mapping. To prevent this, the "real site owner" should be able to credibly threaten to be able to commit additional funds in order to top those of the bad guy.
A full node can currently try to trick an SPV client by omitting transactions. Ultimate blockchain compression might one day solve this. In the mean time, SPV clients could improve their chances of success by querying multiple nodes.
This is tentative.
This will consist of a CLI script that makes it easy to create BurnDNS transactions. This will probably use the testnet.
The first implementation of a BurnDNS client will be a browser-based SPV client using webcoin, where users type in a .burn domain and get a list of addresses. This will let new users easily try out BurnDNS.
Here are some things that could eventually be implemented.
- A DNS resolver
- A DNS server usable with normal DNS clients
- Browser extensions for supporting navigation to
.burnsites
Blockname is a previous proposal for using the Bitcoin blockchain for DNS. BurnDNS is very much a derivative of Blockname, with only a few differences:
- SPV: Blockname can't be used with an SPV client, since it stores data only in OP_RETURN transactions.
- DHT: Blockname uses the telehash network as a DHT. BurnDNS uses only the Bitcoin network; there is no DHT component.
- Scope: Blockname includes support for domain hints, name authority hints, and TLD hints, which BurnDNS does not include.
Namecoin is the original Blockchain-based DNS system. Unfortunately, it ended up not being widely used. Either there just isn't demand for decentralized DNS, or there are some problems with Namecoin's implementation. Hoping that the latter is the case, here are some ways that BurnDNS is hoping to improve upon Namecoin:
- Namecoin has its own blockchain, which makes it harder to implement and more vulnerable to 51% attacks. BurnDNS will piggyback on top of Bitcoin.
- Namecoin was difficult to adopt. BurnDNS aims to provide in-browser support with webcoin.
- Namecoin's mechanics make squatting inexpensive. With BurnDNS, whoever pays the most gets the domain name, making squatting very expensive.
- Will the current burn mechanism result in "dollar auction"-like problems where multiple parties dump in lots of money for control of a domain?
- How can we allow legitimate domain owners to change IP addresses easily without wasting bitcoins? Presumably this would involve some system for cryptographically signing and verifying IP address updates.
- How can we avoid payments being characterized as dust? Presumably by putting more money into the pay-to-pubkey-hash output.