BTW, this is implemented as burn-name and burn-name-writer.
BurnName is a proposal for a simple and practical decentralized name registration system. In BurnName, users burn bitcoins to bid for names. The user who bids the most for a name owns that name, after a delay. BurnName uses the existing Bitcoin blockchain and network, and it can be used by various applications.
- GitTorrent or a similar "decentralized GitHub"
- Domain name registration: your username doubles as a domain name
- Human-memorable Bitcoin addresses: map from your username to your Bitcoin address
In early 2011, Aaron Swartz theorized that it is possible to build a decentralized system that provides secure, human-meaningful names. Since then, several decentralized naming systems have been built, but so far none have become widely used. So, why another system? I believe that BurnName has a novel combination of efficiency, practicality, and careful mechanism design.
- Efficient: BurnName works with simplified payment verification clients, which require 10,000x less bandwidth than a full Bitcoin client.
- Simple: BurnName is a minimal layer on top of Bitcoin.
- Egalitarian: There is no minimum price for registering a username; anyone can afford a username in BurnName.
- Squat-resistant: You cannot make money by squatting a username.
- Slow seizures: Seizing a BurnName username is slow.
- Bitcoin-only: BurnName uses only the Bitcoin network. You can easily build a BurnName client using ordinary Bitcoin libraries.
- Upgradeable: BurnName is designed to allow protocol upgrades.
- Extensible: A BurnName name can be used for arbitrary applications.
In BurnName, a name is a string of 1–16 characters, allowing only lower-case letters, numbers, and dashes. A dash may only occur between two alphanumeric characters. Names are designed to be used like usernames.
To store data, BurnName uses burn-stream, which consists of a series of special Bitcoin transactions. There are two types of operations: a user can bid for a name and attach data to a Bitcoin address.
To bid for a name, a user burns bitcoins. When you bid for a name, you're bidding for that name to be owned by a Bitcoin private key (presumably a private key that you own). Anyone may bid for any name at any time. The owner of a name is the key that has bid the most in total for that name, accounting for a waiting period. Names do not expire.
To attach data to an address, the owner of that name publishes information to the Bitcoin blockchain. Only the owner of an address can attach data to that address. Any application can use these BurnName names by attaching its own data.
To read the data associated with a name, a BurnName client first looks up the address for a name, then looks up the data associated with that address.
In Hanoi, under French colonial rule, a program paying people a bounty for each rat tail handed in was intended to exterminate rats. Instead, it led to the farming of rats.
Designing incentives is difficult, and even a tiny detail can be the difference between a smoothly functioning system and chaos. BurnName takes mechanism design very seriously.
The key tradeoff in decentralized namespace design is the struggle between squatting and seizure. If names are easy to keep for a long time, squatting is easy. If names are hard to keep for a long time, they can be easily seized.
In BurnName, there is no domain authority who gets paid when a bid occurs. Instead, the bitcoins spent to bid for a name are destroyed by being sent to an unspendable address. This is equivalent to distributing the payment amongst all holders of bitcoins.
BurnName uses an auction model for determining ownership, instead of a fixed-fee model. In BurnName, the owner of a name is the key who has paid the most for it. In fixed-fee models like DNS, Namecoin, and Blockchain ID, there are predetermined fees for registering and renewing names.
Fixed-fee models attempt to prevent squatting by charging a registration price for names. By doing this, they price out poorer users from the system. A fixed fee is strange since names are worth vastly different amounts in practice. At any conceivable fee, it would still be worth it to squat the name "apple."
In an auction model, students or users in countries with weak currencies can easily afford their own usernames. If I pick a username that I like but that no one else wants ("occupy-paul-st"), then I can get a great deal on it.
Section 6.2 of Kalodner et al. describes some very interesting ideas for pricing names based on text frequency, name length, and other factors. Of course, this bakes fixed assumptions into the pricing model, which may or may not suit the market. For example, if names were priced using English text frequency, then Chinese names would be underpriced and vulnerable to squatting.
This continuous auction scheme allows names to be taken over by higher bidders; BurnName's waiting period provides a chance to respond to this.
In BurnName, the owner of a name is whoever has bid the most in total for that name, combined with a waiting period.
- Each bid has four important properties:
- the name itself
- the bidder, a Bitcoin key
- the amount bid
- the time of the bid (the block header timestamp)
The first bid on any name is always valid. Subsequent bids on a name become valid after a delay of 14 days, to prevent surprising seizures.
BurnName's mechanism for ownership is extremely simple and easy to analyze; you know what you're getting. Buying a name is an� instance of a continuous all-pay auction.
Squatting is common with DNS, Counterparty Assets, and Namecoin.
Squatting increases name costs and decreases availability; instead of the auction happening on the primary market, squatters create ad hoc secondary markets in which they can auction names.
BurnName is resistant to squatting with the intent to sell the name (squatting for other reasons is still possible). Here's the reasoning:
- A squatter can buy the name at price y and sell it to me at price z.
- Since the squatter paid y, I can outbid the squatter by paying y + ε.
- If y < z, then it doesn't make sense for me to buy the name from the squatter; I can outbid the squatter for cheaper (for the price y + ε).
- If y > z, then the squatter would lose money by paying more for the name than they're selling it for.
- This means that y = z, i.e. the squatter can, at best, break even. Of course this is only a break-even if the squatter is 100% sure that they can sell every squatted name; in practice, squatters would lose money due to unsold names.
Due to the waiting period, it's possible that squatters could offer an "expedited name service," but this would still be risky for them.
Paradoxically, seizing a name can be good or bad. If I have reserved the name "satoshi," I think you would agree that Satoshi Nakamoto has every right to take it from me! On the other hand, if I have reserved the name "occupy-paul-st," you probably wouldn't want the North Korean government to take it from me. Of course, the moral merits of these two situations cannot be encoded into an algorithm.
Disallowing name seizures doesn't quite work: somewhat bizarrely, the Namecoin developers do not own "namecoin.bit" and they have no way of obtaining it, since Namecoin allows perpetual renewals.
In BurnName, the community will "vote with its wallet" on a seizure. If someone attempts to seize the username of a respected activist, the community will contribute money to let the activist keep the name. On the other hand, if Satoshi Nakamoto takes the name "satoshi" from a squatter, no one will help the squatter.
BurnName's waiting period is based on the beliefs:
- It is good to have advance notice before a name you own is seized.
- Waiting is acceptable in the case of a legitimate name takeover, whereas waiting is unacceptable in the case of attacks.
To identify its burn stream, BurnName will use the address 1BurnNameXXXXXXXXXXXXXXXXXXXZtJEfN. The testnet address is mvBurnNameXXXXXXXXXXXXXXXXXXd6F2jp. BurnName's OP_RETURN prefix is 0xCDB6 (Ͷ in UTF-8).
Each BurnName OP_RETURN output script will include a message type after the burn stream prefix. This field will allow the BurnName protocol to be extended in the future with the addition of new message types.
Value Message type
---------------------
00 Bid
01 Data
Bidding for a name is a special burn stream string that asserts that a particular name should belong to a particular Bitcoin key. The bidder is determined to be the key associated with the first input of the transaction.
To bid for a name, we'll set the message type to 0x00. Here's an example bidding output script that bids for the name paul.
Hex ASCII Purpose
-------------------
6a Bitcoin script: OP_RETURN
07 Bitcoin script: push 7 bytes
cd BurnName prefix
b6 BurnName prefix
00 Message type: bid
70 p Name I'm bidding for
61 a Name I'm bidding for
75 u Name I'm bidding for
6c l Name I'm bidding for
You may attach data to a Bitcoin address. The data attached to an address is an append-only log of binary strings. Note that the data isn't associated directly with a name; instead, the address owns a name, and the data is attached to the address.
The address to which to attach data is determined by the key of the first input to the transaction.
Each application should identify its own data by including a prefix.
Currently, the default Bitcoin client only relays OP_RETURN transactions of 80 bytes or less, so it is discouraged to attach strings of over 77 bytes.
To attach data with a name, use the message type 0x01. Here's an example data-attaching Bitcoin script that attaches the data hello to an address.
Hex ASCII Purpose
-------------------
6a Bitcoin script: OP_RETURN
08 Bitcoin script: push 8 bytes
cd BurnName prefix
b6 BurnName prefix
01 Message type: data
68 h Data
65 e Data
6c l Data
6c l Data
6f o Data
Namecoin, created in 2011, was supposed to provide secure, decentralized, human-meaningful names. It built a strong community and became one of the most famous and valuable altcoins. But when measured in 2015, all but 745 of 196,023 names were owned by squatters [Kalodner et al. 2015].
To build a successful decentralized name registration system, it's important to understand where Namecoin went wrong. Here are the most likely possibilities, in my opinion:
- Mechanism design
- Implementation complexity
- Ease of use
- No one wants a decentralized naming system
In Namecoin, the price for name registration is fixed, and renewals are free. Unfortunately, the fees were too low, and squatters took advantage of this.
BurnName uses a continuous auction system completely different from Namecoin's fixed-fee system. For more detail, see name pricing above.
Namecoin has its own independent blockchain with its own rules, using a fork of the Bitcoin client; it would be very difficult to build an independent Namecoin client. In contrast, BurnName is a layer on top of Bitcoin, so a new client could be built using standard Bitcoin libraries.
The BurnName reference implementation will use webcoin, meaning that it will work in the browser. This will make it easier for casual users to get started with BurnName.
It should be easy to get started with writing to BurnName since bitcoins are used to write. To write with Namecoin, you need Namecoins, which are harder to get.
In my opinion, this is still an open question. Perhaps no one really needs decentralized naming! This question can only be answered after the design and implementation challenges have been surmounted.
BurnName is largely inspired by Blockstack's Blockchain ID. Here are a few of the differences:
- Efficiency: BurnName works with SPV clients, which use over 10,000x less bandwidth than full clients. This means that startup time will take a few minutes instead of a few days. That said, some people think that BurnName's SPV strategy is an abuse of the Bitcoin blockchain.
- Scope: The Blockchain ID standard encompasses authentication, verification of other IDs, and user profiles. BurnName is only about registering usernames.
- Pricing: Blockchain ID uses a fixed-fee username allocation model, whereas BurnName uses an auction.
Blockname from telehash was the first system that proposed using the Bitcoin blockchain for storing name data. It also uses an auction mechanism for pricing. BurnName is very similar to blockname. Here's how it differs:
- Efficiency: BurnName works with SPV clients, whereas blockname does not.
- Scope: Blockname is designed as a full DNS system, while BurnName only associates names with data.
- Pricing: BurnName uses the sum of all bids from an address, whereas blockname uses the single highest bid.
These are things that don't seem crucial as part of the MVP, but might be nice later.
It might be good if names could be tranferred between owners. This would introduce some trickiness, since squatters could potentially expedite the process of name purchase.
Speakers of non-English languages, particularly those not using the Latin alphabet, would probably appreciate the availability of additional characters. This introduces security risks such as IDN homograph attacks. There are also payload size concerns, since unicode characters often require multiple bytes and space on the Bitcoin blockchain is very expensive.
It should also be possible to query who owned a name at a particular time. For example, the string apple:2016-04-01 could resolve to the owner of the name Apple on April 1, 2016, rather than the current owner. This could be used to make links permanent while still human-memorable.
Theoretically, a name could be owned in other ways than with a Bitcoin public key. If pay to script hash inputs were allowed to bid for names, this would allow multisignature name ownership, among other things.
If necessary, front-running protection like that of Namecoin could be implemented pretty easily, although I doubt that front-running will be a problem.
An EigenTrust-style trust graph could be constructed between names in order to allow name owners to reinforce each others' rights of ownership. This could prevent unpopular parties from seizing names. Of course, it would also allow mobs to more easily remove someone's rights to a name.
BurnName steals countless ideas from Namecoin, blockname, and Blockchain ID.
Thanks to @xloem on github, Rafi Shamim, and Jordan Lewis for feedback.
Additional comment, re: indexing for SPV clients and UTXO databases.
I mentioned elsewhere my concern that full nodes will have to provide all name registrations for clients of their apis to look up a single name. I said it would be better to place each name in a separate burnstream. The concern then was difficulty for SPV nodes to produce a bloom filter which properly included every possible burn name in order to index all names or new names.
A simpler solution would be to place name registrations in two burn-streams, by having two output addresses instead of one. Then full nodes could lookup individual names or all of them -- and additionally SPV clients could make bloom filters doing the same.
An alternative solution would be to use a bloom filter which identifies an OP_RETURN marker for SPV nodes that want to track a wide set of names.