Skip to content

Instantly share code, notes, and snippets.

@paulkernfeld
Last active November 28, 2016 12:41
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save paulkernfeld/8a43bbae163119f025d7 to your computer and use it in GitHub Desktop.
Save paulkernfeld/8a43bbae163119f025d7 to your computer and use it in GitHub Desktop.
I'm looking for feedback on BurnDNS, a proposal for an efficient decentralized DNS system based on burning bitcoins.

BurnDNS

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.

Transaction

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.

Indexing output

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.

Data outputs

The purpose of a data output is to map from a BurnDNS domain name to an address. It is an OP_RETURN output.

  1. Four BurnDNS prefix bytes, 0x0001f525 that indicate that the output is a BurnDNS transaction.
  2. A procotol version indicator byte, 0x00.
  3. The domain name to map from, not including the .burn suffix. This follows follow the same validity rules as a normal domain name.
  4. A delimiter byte, 0x00.
  5. 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

Mechanics

Fund application

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.

Delay

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

Burning

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.

Bitcoin price

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.

Paid site takeovers

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.

SPV omission attack

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.

Implementation Plan

This is tentative.

Phase 1: Writer script

This will consist of a CLI script that makes it easy to create BurnDNS transactions. This will probably use the testnet.

Phase 2: Web preview

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.

Later phases

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 .burn sites

Prior work

Blockname

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:

  1. SPV: Blockname can't be used with an SPV client, since it stores data only in OP_RETURN transactions.
  2. DHT: Blockname uses the telehash network as a DHT. BurnDNS uses only the Bitcoin network; there is no DHT component.
  3. Scope: Blockname includes support for domain hints, name authority hints, and TLD hints, which BurnDNS does not include.

Namecoin

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:

  1. Namecoin has its own blockchain, which makes it harder to implement and more vulnerable to 51% attacks. BurnDNS will piggyback on top of Bitcoin.
  2. Namecoin was difficult to adopt. BurnDNS aims to provide in-browser support with webcoin.
  3. Namecoin's mechanics make squatting inexpensive. With BurnDNS, whoever pays the most gets the domain name, making squatting very expensive.

Open Questions

  1. Will the current burn mechanism result in "dollar auction"-like problems where multiple parties dump in lots of money for control of a domain?
  2. 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.
  3. How can we avoid payments being characterized as dust? Presumably by putting more money into the pay-to-pubkey-hash output.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment