An empirical study of Namecoinand lessons for decentralized namespace design

Harry Kalodner*, Miles Carlsten*, Paul Ellenbogen*, Joseph Bonneau†, Arvind Narayanan*

*{kalodner,carlsten,pe5,arvindn}@cs.princeton.edu †jbonneau@gmail.com

Princeton University

AbstractSecure decentralized namespaces have recently

become possible due to cryptocurrency technol-ogy. They enable a censorship-resistant domain-name system outside the control of any single en-tity, among other applications. Namecoin, a fork ofBitcoin, is the most prominent example.

We initiate the study of decentralized names-paces and the market for names in such systems.Our extensive empirical analysis of Namecoin re-veals a system in disrepair. Indeed, our methodol-ogy for detecting “squatted” and otherwise inactivedomains reveals that among Namecoin’s roughly120,000 registered domain names, a mere 28 arenot squatted and have nontrivial content. Further,we develop techniques for detecting transfers of do-mains in the Namecoin block chain and provideevidence that the market for domains is thin-to-nonexistent.

We argue that the state of the art in mecha-nism design for decentralized namespace marketsis lacking. We propose a model of utility of differ-ent names to different participants, and articulatedesiderata of a decentralized namespace in termsof this utility function. We use this model to ex-plore the design space of mechanisms and analyzethe trade-offs.

1 IntroductionDecentralized namespaces. We initiate the

study of decentralized namespaces from an eco-nomic perspective. A namespace, as we define it,is an online system that maps names to values. TheDomain Name System (DNS) is the most promi-nent example. A web service such as Twitter thatallows users to claim usernames and create profiles

can be thought of as implementing a namespace. Tobe memorable by humans, namespaces must sup-port arbitrary user-chosen strings as names. To besecure, namespaces must map each name to thesame value for all users; adversaries shouldn’t beable to convince a user that any other value is cor-rect.

The problem of decentralized namespaces haslong been recognized as an important one. TheDNS is a critical yet centralized component of theInternet and those who control it can alter the webfor all users. The controversies around the shut-downs of wikileaks.org and the 2011 domainname seizures by the U.S. DoJ and DHS illustratewhy many researchers and activists have sought de-centralized alternatives [1].

The above three properties — security, user-chosen names, and decentralization — are knownas Zooko’s triangle [2]. Until 2011, designing asystem that exhibited all three was conjectured tobe impossible [3]. The rationale was that enforc-ing the uniqueness of name-value mappings and aconsistent view of the directory for all participantswould require a centralized server or a hierarchy.

Cryptocurrencies and Namecoin. Cryptocur-rency technology enables building a namespacewith all three properties. Put simply, the blockchain is a global, distributed data structure that canbe repurposed as a directory. Miners execute a con-sensus protocol to establish the state of the systemand are incentivized to do so by mining rewardsthey receive in exchange for their participation. Aslong as a majority of miners — weighted by com-puting power — follow the protocol, all users willsee a consistent view of the directory when theyquery it. This in turn gives the system, and hence

1

the underlying currency, economic value, makingminers’ actions profitable to them.

Namecoin is a cryptocurrency that realizes a de-centralized namespace. It is the first altcoin fromBitcoin with its own block chain. It offers thesame features as Bitcoin with the addition of aname/value store that can be used to hold arbitrarydata (see Section 2). The name/value store supportsvarious applications; primarily, Namecoin has beenused for domain-name resolution for the ‘.bit’ alter-native TLD, and by the online identity service, One-Name, which utilizes the Namecoin block chain torecord data about its members.

Namecoin offers a novel solution to the techni-cal challenges of decentralized namespaces. How-ever, there are also economic challenges. Thesearise from the fact that although namespaces theo-retically support infinitely many names, the supplyof names that are memorable and meaningful to hu-mans is scarce. Allocating these names to users istherefore a mechanism-design challenge. The cen-tral thesis of this work is that this mechanism de-sign challenge is far harder than realized. A systemthat gets it wrong may “work" in a narrow technicalsense, but may not be useful to real users.

Specifically, there are several crucial questions toconsider: how do we model the economic behaviorof the users of a namespace and what are the goalsof mechanism design for namespaces? How welldoes Namecoin succeed at attaining these goals andwhat are its limitations? If Namecoin is not theideal design, can we analyze the design space as aguide to the creators of future decentralized names-paces?

Our contributions. Along the above lines, wemake the following contributions. We begin byproposing a model of utility of different names todifferent participants and articulating desiderata ofa decentralized namespace in terms of this utilityfunction (Section 3). We highlight the difficulty ofmechanism design even in a toy model and explainthe importance of making the model more realisticby incorporating extensions such as time-varyingpreferences.

The central contribution of this paper is a thor-ough empirical analysis of the Namecoin ecosys-tem. We develop a series of criteria based on theblock chain, network behavior, as well as content todistinguish active websites from parked or squatted

names (Section 4). This allows us to iteratively fil-ter our dataset of around 120,000 registered namesin Namecoin, leaving a mere 28 that are not squat-ted, and have nontrivial content.

We then delve deeper into the economics ofnames. Namecoin has a built-in ability to transfernames, which is a secure way to trade them usingthe block chain. However, it is not obvious whichtransactions correspond to such sales, as opposed toregular name updates. We develop a novel analytictechnique to distinguish the two types of transac-tions and find evidence for about 250 transactionsin the entire history of Namecoin that may representsales of names (Section 5). Of course, it is possiblethat more sales have occurred off the block chain,but there doesn’t appear to be a widely known mar-ketplace for Namecoin names.

Based on all the empirical evidence we present,we are left to conclude that the Namecoin ecosys-tem is dysfunctional. The vast majority of regis-tered names represent squatting and there is littleevidence of a secondary market for names. Whilethere could be many factors that explain the lackof adoption, there appears to be clear room for im-provements in the design to minimize squatting andother problems. To this end, in Section 6, we ex-plore the design space of decentralized namespacesand make recommendations.

Why study namespaces? Although we findthat the Namecoin ecosystem is in disrepair, study-ing namespaces is important. While there cur-rently doesn’t seem to be widespread dissatisfactionwith today’s DNS causing users to seek censorship-resistant alternatives, the existence of such alter-natives provides a valuable hedge against a poten-tially abusive central authority. Besides, domainnames are just one application of namespaces. Cen-tralized directories for user public keys have faredmuch less well than DNS, and the service One-Name, which we discuss in Section 8, is an inter-esting alternative. Yet other applications for names-paces such as control of digital assets have beenproposed. And of course, the problems posed bynamespaces are intellectually interesting to study.We think decentralized namespaces have many im-portant applications, but their promise hasn’t beenrealized so far. Our work helps understand why thismight be and lays the groundwork for a more rigor-ous approach to building such systems.

2

2 Background: NamecoinIn this section we cover the background of

Namecoin. We begin by looking at the history ofthe cryptocurrency and then explain why a blockchain can be used for our definition of a namespace.We then proceed to discuss the technical design ofNamecoin and the mechanisms used in the design.We conclude this section with a discussion aboutthe applications of Namecoin.

A note about the term ‘namespace’. In com-puter science, a namespace is simply a containerfor a set of names, so that names in a single names-pace must be unique but the same name can existin different namespaces. We have chosen to use theterm in a related but different way: it’s a system thatincludes client and server software, users, a mecha-nism, and so on. In fact, Namecoin contains names-paces in the computer science sense, which we termsubspaces in this paper.

2.1 HistoryNamecoin is an alternative cryptocurrency, or alt-

coin, modeled after Bitcoin [4]. Furthermore, it isthe first altcoin in the sense that it was the first tocreate its own block chain, separate from Bitcoin’s.Namecoin shares many similarities with Bitcoin,including the same method for proof-of-work, thesame coin cap, the same block creation time, andall of the same transaction operations (with a fewadditions). Namecoin was inspired after discus-sions about a BitDNS [5] protocol using a blockchain to manage a domain name lookup service.The motivation was that a central authority man-aging domain names, such as ICANN, requires toomuch trust in a single entity and represents a sin-gle point of failure. The first Namecoin block wasmined in April 2011, and as of this writing, over215,000 total blocks have been mined in the Name-coin system. Because of its similarities with Bit-coin, Namecoin was able to be merge-mined andhas been merge-mined with Bitcoin since October8, 2011 (see the next subsection).

2.2 Description of the block chainNamecoin is minted and maintained by a decen-

tralized peer-to-peer network.1 Namecoin transac-tions require the digital signature of the accountholder to prevent theft, and every transaction is

1This description is adapted from [6].

published in an append-only hash chain, called theblock chain. The block chain can be extended withnew transactions by any participant, and such par-ticipants (known as miners) obtain newly mintedNamecoin currency (NMC) and transaction feesfrom the transactions for performing this function.Extensions to the block chain require a proof-of-work that rate-limits the process (to approximatelyone extension every ten minutes) which enables asteady inflation rate, ample competition among par-ticipants to extend the block chain, and adequatetime to obtain and verify the history of the blockchain for new participants. Informally, the proof-of-work protocol in Namecoin is intended to main-tain the following two essential properties about theblock chain:

• Every party eventually agrees on the order andcorrectness of transactions in the block chain.

• Any party can publish a transaction (for afee), which will then be verified and, if valid,included in the block chain within a smallbounded delay.

One use case for a block chain is a tamper-evident log. That is, it can be used as a data struc-ture that stores user-supplied data, and allows usersto append data to the end of the log. Each new blockhas a hash of the previous block, so if data that isearlier in the log is altered, it will be detected. Ifan adversary wants to tamper with data anywherein this entire chain, in order to keep the hash point-ers consistent, he will have to tamper with the hashpointers all the way up to and including the cur-rent block. Thus it emerges that by just remember-ing the single hash pointer of the head of the chain,users essentially remember a tamper-evident hashof the entire list, all the way back to the genesisblock. Namecoin, and all block chain based cryp-tocurrencies, use this tamper-evident log in order torecord all the transactions between users.

Block chain security. The value and stability ofa cryptocurrency are directly related to the amountof proof-of-work involved in the calculations of theblocks because this work is what keeps the datadistributed and secure in the tamper-evident blockchain. For both Bitcoin and Namecoin, the proof-of-work is shown by calculating the hash of a newblock and a random nonce over and over until the

3

calculated hash has a certain number of leading ze-ros. The number of leading zeros required by thehash is referred to as the difficulty threshold. Name-coin enjoys a very high difficulty threshold for theproof-of-work because it is similar to Bitcoin andsupports “merge mining” with Bitcoin. This meansthat miners who are mining Bitcoin can also chooseto mine Namecoin at the same time with no ex-tra work. Essentially, this is because the miner isusing their computational power to solve a crypto-graphic puzzle that satisfies the proof-of-work forboth block chains at the same time. This is advan-tageous for the miners because they are rewardedwith coins from both systems, and helps Namecoinbecause it gives the Namecoin network a vastly in-creased amount of hash power over what it wouldhave if it did not support merged mining. Includ-ing the merge miners, Namecoin has aproximatelyone third the hash rate of Bitcoin. This providesresilience to a 51% attack, although a sufficientlylarge Bitcoin mining pool could still execute thisattack.

2.3 Technical details of namesIn this subsection and the next, we present details

of Namecoin, separating the technical solution fromthe mechanism design choices.

The feature that separates Namecoin from Bit-coin is that Namecoin is a namespace, and can beused to register name/value pairs that can be storedin the block chain and traded amongst individu-als. This registration is done using the three scriptoperations exclusive to Namecoin: NAME_NEW,NAME_FIRSTUPDATE, and NAME_UPDATE. Inorder to understand the registration process, wethink it is helpful to walk through the registrationprocess of name, roughly following Figure 1.

NAME_NEW. To start, the user will need to se-lect a coin to be crafted into a token (or specialcoin) that represents a name and whose value canbe changed by whoever possess the token. Thenext step to register a name is to make a transac-tion that uses the NAME_NEW script operation in atransaction sending the token from one of their ad-dresses to another. Using NAME_NEW, a user canindicate an interest in name for a name/value pairby posting a hash commitment of the desired namein the scriptPubKey of the transaction. The reasonthe user posts the name in hashed form first, rather

than in plaintext, is to prevent front-running, whichwe will explain in Section 6. The NAME_NEW op-eration acts as a signal in the block chain for nameparsers to indicate that the next part of the script-PubKey will be the hash commitment to a name.

NAME_FIRSTUPDATE. After doing this, andwaiting for 12 or more blocks on top of the onecontaining the NAME_NEW transaction (to ensurethat the block chain reaches consensus on theNAME_NEW transaction), the same user can usethe output of the NAME_NEW transaction as theinput for the NAME_FIRSTUPDATE transaction.Once completed, this will associate the chosenname with value selected by the user. Simi-lar to NAME_NEW, NAME_FIRSTUPDATE allowsdata to be posted in the block chain as part of thescriptPubKey of a special transaction. To create aNAME_NEW transaction, a user will select, as input,the output of the NAME_NEW transaction. They willthen use another address they control as the out-put for the transaction. The scriptPubKey of thistransaction will contain a NAME_FIRSTUPDATE,the name desired, the random nonce used in theNAME_NEW hash commitment, and the first valuefor the name to take.2 In order for this transaction tobe valid, a miner will verify that the name and theprovided nonce do, in fact, hash to the commitmentin the appropriate NAME_NEW transaction. The out-put of this transaction now contains the token repre-senting the name/value pair for name and value,and whoever can unlock and spend the output canutilize the final new operation, NAME_UPDATE.

NAME_UPDATE. The third and final new op-eration in Namecoin is the NAME_UPDATE opera-tion. Again, this operation’s arguments (the nameand newValue) are stored in the scriptPubKey ofa special transaction. This transaction must have asinput a NAME_FIRSTUPDATE or NAME_UPDATEoutput with the same name. This operation hasthree uses: updating, renewing and trading a name.If the user wants to change the value associatedwith a given name, they will update name withthis operation, providing a newValue. If namescan expire, as they do in Namecoin, then this opera-tion can also be used to renew a name by providinga newValue that is the same as the old value.

2There are also other operations that exist for reasons ofcompatibility with Bitcoin; this seems to exist to minimizechanges to Bitcoin’s script handling code.

4

Figure 1: Namecoin name registration protocol described in Section 2.3

In either of these cases, the user will use an ad-dress they control as an output of the transaction.The final reason to make a NAME_UPDATE trans-action is to trade the special coin to another user.In this case, the user will put, as an output, oneof the other user’s addresses instead of their own.Once the transaction resolves, the other user willhave control over the special coin and can changethe value to whatever they deem fit. Because theownership of name is associated with the owner-ship of the special coin, if the buyer is paying forthe name with Namecoins, the exchange betweenthe payment and the name can be atomic (meaningthey happen in the same transaction and either areonly valid if the other is as well).

2.4 Mechanism design

Fees. Namecoin has been implemented withvarious fees and protocols to incentivize the be-haviors of the users. The special token used inthe NAME_NEW transaction has a value of 0.01NMC. This coin will be not be spendable likeother Namecoins while it has a name attachedto it. For all of the transactions, NAME_NEW,NAME_FIRSTUPDATE, and NAME_UPDATE, thedefault behaviour is to have the user pay a transac-tion fee to the miner. The current expected transac-tion fee, which is programmed into the Namecoin

client, is 0.005 NMC on each transaction. Histori-cally, Namecoin also had a network fee attached tothe NAME_FIRSTUPDATE transaction. The net-work fee is different from the transaction fee; thetransaction fee is paid to the miners, whereas thenetwork fee was destroyed (with an OP_RETURN)when a NAME_FIRSTUPDATE transaction wasconfirmed. The network fee varied over time —it started at 50 NMC at the genesis block, but de-creased by a factor of 2 every 8192 blocks (whichis approximately 2 months). The purpose of the net-work fee was to have a large initial cost to claimingnames to deter users from quickly claiming all thedesirable names, but then decay off so that eventu-ally the cost of registering a name becomes negli-gible. As of block 85585, the network fee becamesmall enough that it rounds to 0 and is no longeradded onto the transaction. The current implemen-tation of Namecoin has no fees other than the trans-action fees and the investment of the token coin.

Expiration. Namecoin has an expirationtime for names. Originally, the time periodfor a name to expire was 12,000 blocks, butby March 2012, the expiration period was in-creased to 36,000 blocks (which comes out toabout 250 days). If a particular name hasn’tbeen mentioned in a NAME_FIRSTUPDATEor NAME_UPDATE in 36,000 blocks, the name

5

becomes available again for any user to claimwith NAME_NEW and NAME_FIRSTUPDATE.Similarly, a NAME_UPDATE must cite aNAME_FIRSTUPDATE or NAME_UPDATEthat is less than 36,000 blocks old as input.

Changing the protocol. Changing the protocolin a cryptocurrency requires a “hard fork” or a “softfork” depending on the extent of the change. In amature system like Bitcoin, this is very difficult.In a fledgling system like Namecoin, however, itis much easier has happened multiple times. Boththe addition of merge mining with Bitcoin, and theincrease in expiration length were not initially inthe design of Namecoin and required hard-forkingchanges. In order to make these changes, theNamecoin community decided on arbitrary blocksat which point the new protocol would be enforced.Explicitly, up to block 19,199 blocks that weremerge mined with Bitcoin were not allowed into theNamceoin block chain, but starting on block 19,200they were.

2.5 ApplicationsThere are many different subspaces in Namecoin,

and the different subspaces correspond to applica-tions. When claiming a name, a user prepends thename with a subspace ID and a slash. Namecoinwas created to be very general so that it would beuseful for any application that would benefit froman online name/value store. While d/ has the mostregistered names, there are many used subspaces inNamecoin. The separation of namespaces is notenforced by the protocol in any way, but merelyagreed upon by consensus of all users, analogousto open web standards.

.bit Domains. The vision for Namecoin wasto use one of these subspaces for DNS lookup inthe .bit TLD. Explicitly, Namecoin names associ-ated with .bit domains are prepended with the sub-space ID d/. If a user wanted the domain exam-ple.bit, they would claim the name d/example.The owner of example.bit would then set the valueto their server address in a way that would be under-stood by .bit compliant DNS servers as described inthe .bit specification [7].

Most major web servers, such as Apache, ngnix,and lighthttpd will accept connections through .bitdomains with minor modifications to their per-siteconfiguration files.

There are a number of ways to resolve .bit do-mains to IP addresses with varying levels of se-curity. The most secure option is running localDNS resolution software. The three major projectscreated for this purpose are NMControl [8], a lo-cal DNS server, FreeSpeechMe [9], a Firefox add-on, and DNSChain [10], another browser extension.NMControl and FreeSpeechMe both hold a localcopy of the block chain and query it for values as-sociated with .bit domains. They parse the valueof the name using the specification and seamlesslydirect the user to the resolved IP address.

There are a couple less secure options to access.bit domains. Users can connect to specific DNSservers such as OpenNic [11] which support resolv-ing .bit domains. However this requires trustingthat the DNS server is working properly and ac-curately reporting results. A final option is usinga proxy server hosted in a standard TLD. This re-quires no local configuration, but users must go toexample.bit by visiting example.bitproxy.com.

OneName. The name/value data store in Name-coin has applications beyond DNS. OneName is anonline identity service that runs on top of Name-coin, making use of the data store. OneName isa centralized service, but one can use other clientsto interact with the block chain in a way that’sinteroperable with OneName. The idea behindOneName is that a user can have a name/valuepair in the block chain that associates said namewith different online identities such as an email,GitHub, Twitter, and Bitcoin address. A One-Name user can then confirm ownership of ac-counts on any of these services by referencing theirOneName name through some messaging channelin each respective system. For example, if Al-ice wants to tie her twitter username to her One-Name username, she must tweet the message “Ver-ifying that +Alice is my openname (my Bitcoinusername). https://onename.com/Alice”.This is similar to the verification scheme Keybase[12] uses. A OneName account also has an asso-ciated Bitcoin address so users can easily find anaddress to use to send Bitcoins to a particular indi-vidual, if they want.

In order to make a OneName identity, a usercan visit OneName’s website to create an account.A user makes an account by selecting a usernameand then optionally entering in their actual name,

6

their account names, a short biography and picture,and a Bitcoin address. OneName takes the infor-mation given to it and automatically puts it intoa name/value pair, with the name equal to the se-lected username, and the value containing all theother data. If the username is not already claimedby some user in the Namecoin subspace u/, thenOneName posts this pair into the block chain. If itis already taken, the website will ask the new userto select a different username. If a user so desires,they can alternatively manually create a name trans-action using the Namecoin client to create a namevalue pair with a name in the u/ subspace and avalue formatted to match the OneName specifica-tions. To incentivize using their website interface,OneName covers the Namecoin fees for their users.

3 Modeling namespacesNames are scarce. Many types of systems map

keys or names to values. In his essay introducinghis triangle, Zooko considers naming systems thatinclude a system mapping PGP key fingerprints tokeys. Fingerprints are hashes of keys. This wouldnot qualify as a namespace by our definition be-cause users cannot pick arbitrary names — thatwould require finding the hash pre-image of an ar-bitrary name (fingerprint), a hard problem by thedefinition of a hash function. Zooko (and similarprior work) considers such systems to lack humanmemorability of names. We replace this criterionwith that of user choice of names, which is roughlyequivalent but easy to define rigorously.

In a system that maps key fingerprints to keys,names are fungible and essentially infinite, and thusnot scarce and have no market value. On the otherhand, in any system that we call a namespace,scarcity is an almost inevitable consequence of freeuser choice. Even when names are scarce, the sys-tem architecture can make names more or less valu-able. For example, usernames on Twitter are morevaluable than on Facebook — the username or han-dle is a relatively important way to find a user onTwitter, whereas on Facebook it is done more oftenby navigating the social graph.

The scarcity of names makes the design ofnamespaces challenging. But it also makes theproblem particularly amenable to cryptocurrency-based solutions. Since names have market value,

and participation in the primary market requires theassociated cryptocurrency, the currency becomesvaluable. This incentivizes miners, making the sys-tem secure.

The (non) role of trademarks. Scarcity is alsoan issue in centralized namespaces, but it manifestsin different ways. One key goal of most central-ized systems is trademark protection. The trade-mark system can be seen as a legal mechanism toaddress the problems of name scarcity and limits ofhuman memorability in the real world, independentof any particular technological system. Most cen-tralized systems support some form of arbitration ordispute resolution in which trademark plays a role.3

In a decentralized system, on the other hand, thereis no easy way to enforce any rules that cannot beencoded algorithmically. As of yet there is no wayto cryptographically assert that one is the owner ofa trademark, and this may be impossible given thecomplexity and nuance of modern trademark law.

Primary and secondary markets, algorithmicagents. We use the term primary market to meanthe part of the market where new names are issuedto users for the first time. By contrast, the sec-ondary market deals with the sale of a name alreadyin use.

Whom do names “belong to” before they are soldon the primary market? To answer this, we must un-derstand decentralized agents. Any cryptocurrencycan be thought of as an algorithmic agent executedas a global, distributed computation. The agent hasno capability to store private information but it canhold funds and transact with users of the system.Bitcoin encodes a very simple agent whose onlyfunction is to release currency into circulation at apre-specified rate.4

In a nutshell, the agent implemented by a names-pace initially owns all names and sells them tousers. As we’ll see in Section 6, there aremany variants including whether names are sold orleased, whether or not they can be bought back,how names are priced, what the agent does with thefunds received as payment, and so on.

3For example see ICANN’s Uniform Domain-NameDispute-Resolution Policy [13].

4At the other extreme, altcoins such as Ethereum allow anyuser to create an agent by making the central agent “Turingcomplete,” that is, flexible enough to execute arbitrary pro-grams specified by users on their behalf.

7

The most straightforward implementation of asecondary market is to leave it entirely external tothe system. This is the approach taken by Name-coin, but again, a variety of choices are possible.We elaborate in Section 6.

Squatting. Even though names are scarce, it’snot obvious what “squatting” means. After all, ma-terial goods are scarce, but we don’t usually char-acterize car owners as squatting on them. The dif-ference is that names have (vastly) different utilityto different users. A squatted name is one that isowned by a user whose utility for that name is closeto zero (or very small compared to the user who hasthe most utility for that name), purchased in hopesof selling to another user whose utility is higher.

Is squatting a problem for the system? This is atricky question. If squatting exists merely becauseone side of the primary market is an algorithm anddoesn’t charge market price, then squatters couldbe seen as analogous to brokers or ticket scalpers.Such agents are sometimes considered to performa useful function as market makers [14], or at leasttolerated, but not considered an existential threat tothe functioning of the market.

On the other hand, squatters can be viewed asanalogous to land speculators. This analogy is sup-ported by the fact that names, like land but unliketickets, are not fungible. The speculator may havezero utility for a name and makes no use of thename himself; he hopes that demand for a namewill rise in the future, and may therefore not sellto a buyer who has a positive utility today. Thiscould lead to a market failure in a few ways. Theuncertainty around future demand means that somenames may be squatted indefinitely, while legiti-mate users may end up with sub-optimal names. Ifmost valuable names are locked up by squatters, itmay prevent the growth of the system, in turn pre-venting the growth in market price for names thatspeculators are hoping for. Land speculation hasalso been criticized as contributing to a market fail-ure [15].

In this view, squatting may exist and may beproblematic even if the primary market is able todiscover the market price. But if the primary mar-ket is algorithmic, it only exacerbates the squattingproblem.

Complexity of the utility function. Our argu-ment above is essentially that the utility of a given

name to a given user may vary with time. Thisis particularly relevant to cryptocurrency-basednamespaces — in addition to the usual network ef-fects that make the adoption of some new productschallenging, cryptocurrencies need to “bootstrap,”which presents an additional difficulty in gettingoff the ground. A cryptocurrency may not be suf-ficiently secure if it has too few users. Thus, manyusers may have a zero or negligible utility for allnames until they decide that the namespace is se-cure enough and has enough users to be worthy oftaking seriously.

Another aspect of complexity of the utility func-tion is diminishing marginal utility. A user namedJohn Smith may want either the name JohnSmithor john-smith but not necessarily both. Time-variation and diminishing marginal utility make themechanism design problem very tricky.

Suppose, to the contrary, that utility functions aretime invariant, and utility functions of a user for dif-ferent names are independent. Then we may statethe goal of the system as ownership of each domainby the user with the maximum utility (or willing-ness to pay) for that domain, as long as that value isabove some threshold. We can easily realize this bymaking the primary market a second-price auctionwith a reserve price. No secondary market wouldbe necessary.

Of course, this is oversimplified. Let’s add di-minishing marginal utility to this model. Sup-pose there are 10 John Smiths in the world and10 variations of the name JohnSmith. A 10x10matrix describes the utility of each user for eachname. Further, none of these users has any util-ity for more than one name. Now we can state awelfare-maximization goal of finding the assign-ment of names to users that maximizes the sumof each user’s utility for his assigned name, whichtranslates to a maximum weighted graph matchingproblem. Or we could be happy with a Pareto-efficient assignment; since this is one-sided market(names aren’t agents), this is the house allocationproblem [16]. This shows that even in a highly sim-plified setting with a finite number of names and thesame number of users, the mechanism design ques-tion is very tricky.

When we add time-varying preferences to themodel, it is unclear if we can even formally statea goal for the system. The harder we make it for

8

a user to hold on to a purchased name, the easierit becomes for an adversary to “seize” a name (seebelow).

At any rate, the fact that preferences are timevarying appears to be part of the reason that namesin Namecoin expire and must be renewed; in effect,they are leased rather than purchased outright.

Seizures. The Namecoin community considers ita major goal to prevent “seizures” of domain namesby adversaries [17]. To prevent seizures, then, itmust be easy to hold on to a name after buyingit. This is in tension with preventing speculation,which works by buying a name and holding on to itdespite other people wanting it.

The reason it is even technically possible to pre-vent such censorship in the face of a well-fundedadversary is that the adversary can’t possibly pre-emptively buy up all the names that the victimmight use. For example, Wikileaks might find anyname with the string “wikileaks" in it to be accept-able, even if not ideal, for their purposes. In otherwords the victim’s utility function has a large sup-port; the adversary’s utility for a name is contingenton the victim owning that name.

4 Analysis of .bit domainsIn this section we analyze the current state of .bit

domains. We begin at the highest level, looking atthe repetition of values in order to detect squatters.Next we look at how many .bit domains are set upwith query-able values. Finally we actually visitthese query-able names and analyze the content wefind there.

4.1 Detecting squattersWe investigate the balance between squatters and

other users in the .bit subspace. As we discussed in3, squatting is a critical issue in any decentralizednamespace. We look at Namecoin in order to get arealistic view on the proliferation of squatting.

Namecoin possesses the same pseudonymityproperties as Bitcoin and thus it is difficult to groupnames by their owner. Names are owned by indi-vidual addresses rather than by identities and it isa common practice to keep each purchased nameunder a different address. Because of this, it is dif-ficult to assess how many names any single entityowns.

Figure 2: Analysis of squatting. Names whosevalues occur more than about 10 times canbe safely considered to be squatted. In fact,the graph shows that the majority of namesare held by prolific squatters who control thou-sands of names.

However, many squatters are easily identifiedthrough the values they set for the names they own.Since there is no built-in functionality for the list-ing and sale of names in Namecoin, squatters usethe values of names they own to display contactinformation. This information generally comes inthe form of either contact information stored di-rectly in the value of a name, or contact informationstored at the IP address to which the name resolves.We observed that a squatter’s contact information isgenerally constant among all the names they own.Thus, by measuring the extent to which values areduplicated on the block chain, we can estimate theratio of squatters to genuine users.

Regular .bit domain owners are unlikely to usevalues that are highly replicated. The value of adomain points to an individual server and most areunique. Repetition may occur in this circumstanceis when multiple names resolve to the same point.This could occur when a single DNS server is re-solving a large number of names to different web-sites. However when we performed the contentanalysis described in Section 4.3, we found that thisdoes not happen currently.

There is no definitive threshold for deciding ex-actly how often a value has to occur in order toassume a squatter has been detected. Howevereven the coarsest grained approach displays a mas-sive amount of squatting on the block chain. Of

9

Type of resolution CountNameserver URL 3200Nameserver IP 148Single IP 5848Multiple IP 2Single IPv6 2Multiple IPv6 1Tor 9Alias 23Only subdomains 2Total 9354

Table 1: Comprehensive list of .bit domain res-olution methods currently in use.

the 196023 currently active names, there are only34361 unique values.

In Figure 6 we examine the fraction of current.bit names that are squatted. We sorted all of thevalues that occur by the number of times they oc-cur. The graph has a very sharp initial drop as weremove all names with values that occur only a fewtimes. This leaves the majority of domains to dropoff very slowly as we remove bigger and biggersquatters. Using a cut-off of n = 10, it appears safeto say that at least 76% of .bit domains are held bysquatters.

4.2 DNS recordsWe now examine how .bit domains are used by

genuine users. Only 9354 out of the 119624 .bit do-mains make any attempt to resolve to an IP address.Out of these a variety of types of IP resolution areemployed.

In order to support DNS lookups, Namecoin pro-vides a specification that allows for the support ofmost DNS record types. A name’s configuration isstored in a JSON dictionary object which is placedin a name’s value. Domain’s can be configuredin a number of different ways. The main meth-ods are directly setting one or more IP (or IPv6)addresses or setting one or more secondary name-servers which hold information about a domain.Additionally records can link a name to a numberof hidden-services URL schemes like .onion [18]and .i2p [19].

Namecoin supports a number of different nameresolution methods. Different methods have differ-ent properties and thus it is interesting to inspect

Criteria applied CountTotal Names 196,023Valid DNS 9354Curlable 5374Not squatter 745Without duplicates 455Without errors 278With content 222Without ICANN hostname 28

Table 2: Number of .bit domains which resolveto real content

how people are setting up their domains. The vastmajority of names point directly to an address. Thisincludes people using IP, IPv6, and Tor. This is byfar the most privacy preserving method since the IPaddress is drawn directly from the block chain. Aclient can simply look up a name in the block chainand immediately connect to the server. However,this privacy comes at the cost of flexibility since theserver is directly encoded in the block chain and cannot be changed without an update.

The much more flexible configuration, also com-monly used, is name server delegation. Rather thandirectly listing an IP address in the block chain, oneor more name servers are listed. This way a nameowner can update their IP address without modi-fying the block chain. However this is an inse-cure delegation since Namecoin can not enforce anyproperties regarding the action of the external nameserver. The server will have full control over itsinteraction with users including the ability to tracklookups or return results which aren’t globally con-sistent.

4.3 Domain content analysis

After understanding how people connect theirnames with IP addresses, we explored what sortof content is reachable through .bit domain names.We attempted to download the front page of eachof these 9354 domains over port 80 (HTTP). 3881of these domains were unreachable or didn’t serveweb content, leaving us with only 5374 responsivedomains.

Looking at the content of the servers’ responses,we found that of the responsive 5374 domains,4629 are owned by 3 different squatters. These do-

10

mains serve nothing of value and caused massiveinflation in our reachable domain count.

Removing the squatters, we count 745 viable do-mains. However, many of these pages are mirrors orduplicates of each other. After removing 290 suchduplicates, 455 domains remained.

A large number of pages were either error re-sponses from the server or default pages from vari-ous web servers. Neither of these can be considereduseful content. There were 177 such domains, andremoving them left us with 278 domains.

Out of the remaining sites, many had very smallamounts of content consisting of only a few wordson a blank page like, "Welcome to mysite.bit."These pages, though valid uses of Namecoin, pro-vide minimal utility to a visitor. Thus, we decidedto look at only pages consisting of 15 or more wordsand images which brought us down to 222 domains.

These 222 domains make up the only websitesreachable through .bit domain names which haveany real content on them at the time of this analy-sis. We are further interested in the subset of thesepages which don’t come from a server that is acces-sible through a standard ICANN TLD as well. 83 ofthe pages directly redirect the user to a standard do-main and 111 were manually identified as pointingto the same site as a standard domain. The domainswhich had ICANN hostname’s along with their .bithostname were manually identified and pinged toensure matching IP addresses.

This left us with 28 pages serving non-trivialcontent that is uniquely available via .bit.

Our approach to analyzing content suffers froma few limitations. First of all we only queried themain domain over port 80, thus if any of the serversonly respond to subdomains or only serve contentover HTTPS, they are not included. Additionallywhen we detect how much content is on each page,we do not follow links and thus content could behidden behind links. Despite these limitations webelieve that we have missed very few legitimate do-mains.

4.4 Examining Squatter Name ChoiceAs we have seen, many individual squatters buy

up very large numbers of domains. We now explorewhat sort of categories these names fall into and tryto interpret the decisions these squatters have made.Here we explore two potential measures of name

Figure 3: For each 1≤ n≤ 1,000,000, the prob-ability that .bit versions of domains with Alexarank approximately n are registered.

desirability, one using Alexa ranking, and one usingthe length of the name.

We can see from Figure 3 and Figure 4 that thereare patterns to the names that squatters have ac-quired. In Figure 3, we can see that squatters haveclaimed the majority of very high ranking Alexasites.

In Figure 4 we see that there is a preference forshorter names. Table 3 shows that in fact all one-and two-character names are taken. It is not un-til we get to names with at least three charactersthat there are names available to register. Beyondthree characters, the combinatorial nature of namestrings makes it infeasible to register all names ofthat length. There are more names with a lengthof 4 available than there are total names registeredcurrently.

Alexa ranking and name length are not an ex-haustive description of squatter behavior. Futurework would attempt to better model the valuationthat squatters and other namespace participants puton names.

5 Secondary market analysisNext, we seek to understand and quantify how

names move between users. Our basic scenariois that Alice owns the name ‘d/example’ and Bobwould like to purchase it from her. We explore var-ious ways this sale can occur and how these salescan be detected.

11

Figure 5: Anatomy of an atomic name transfer. Both the name and the payment are included inthe same transaction, so one cannot fail to transfer to the other party without the other failing totransfer.

Figure 4: The number of Namecoin namesregistered as a function of name length.

Name length Percent registered1 100.00%2 100.00%3 58.61%4 1.00%5 0.02%...

...

Table 3: Percent of all domains of registered bylength. All possible names are counted combi-natorially using the rules given by [7].

5.1 Detecting atomic transfersThe safest way to buy and sell Namecoin names

is through the use of atomic transactions. This is animportant technique in cryptocurrencies wherebytwo parties can exchange digital assets (such as aname in exchange for currency) without a trustedintermediary without either worrying that the otherwill abscond after receiving her half of the bargain.We show how these transactions work in Figure 5.In an atomic transaction, Alice and Bob make theirexchange in a single transaction. In the simplestform of atomic name transfer, Bob creates a trans-action which transfers his payment to Alice andtransfers ‘d/example’ to him. He then sends thistransaction to Alice, the owner of the name, whoverifies it, signs, and broadcasts the transaction tothe block chain. Both Alice and Bob’s signaturesare locked to the inputs and outputs of the transac-tion so neither input can be spent individually with-out the full transaction. This transaction providescryptographic security to both Alice and Bob sinceeither both the name and coins will be exchanged ornothing will. Although there is nothing inherentlydifferent looking about this transaction on the blockchain, there are a few possible techniques to detectthem by implementation quirks.

The Namecoin client is a fairly underdevelopedpiece of software and thus there is no built-inmethod of performing atomic transactions. In or-der to accomplish this task, the Namecoin RPC

12

client must be used from the command line. Inorder to simplify this task, a Namecoin developercreated ANTPY [20], a piece of software to auto-mate the creation of atomic transactions. This soft-ware has the quirk that the buyer’s payment goesto the address that the seller held the name in. Tofind these transactions we queried the block chainfor transactions with a NAME_FIRSTUPDATE orNAME_UPDATE input from the same address as anon name output. We then further reduced this setby eliminating transactions where the name stayedat the same address.

We searched throughout the history of the Name-coin block chain for transactions fitting this specifi-cation. Our query returned 13 transactions whichwe believe represent all transactions built by theANTPY script. However this by no means repre-sents all sales on the block chain. We next attemptto discover atomic transactions in a different way.

A implementation-agnostic method for detectingatomic name transfers is to find transactions thatclearly use change addresses. This occurs whenthere are two non-name outputs in a transactionthat has a name input. In this case the buyer didnot want to pay all of his input to the seller andthus kept some for himself. This leaves the transac-tion with 3 outputs. Under normal circumstances,NAME_UPDATE transactions will only have twooutputs, a name output and a change address. Thusevery transaction with three outputs is very likelyan atomic name transfer.

In the history of the Namecoin block chain, wefound 6 transactions fitting this form. However 5 ofthe 6 were also detected by the previous (ANTPY)criterion.

The 14 atomic transactions which we detectedare a lower bound for the number of name trans-fers. We are unable to query for all atomic trans-actions since if the buyer doesn’t want any changefrom a purchase and the seller gives the buyer a newaddress to send payment to, the transaction is indis-tinguishable from a regular non-transferring nameupdate.

5.2 Deriving an upper bound on numberof sales

Following up on our lower bound from the pre-vious section, we now derive an upper bound onthe number of name sales using data from the block

Figure 6: Number of transfers detected basedon squatting threshold. For each n on the x-axis (5≤ n≤ 25), we plot the number of squat-ter→ non-squatter transactions detected if wecharacterize names whose values occur n ormore times as squatted.

chain. Whereas atomic transactions, can (some-times) be recognized simply from their contents,other name sale transactions are not recognizable.Here the payment could be a separate transaction oreven made in a currency other than Namecoin. Wewould hope that we could detect changes in nameownership by looking at changes in which key ownsa name. However, since the Namecoin client de-faults to sending names to new addresses on update,there is no way to look at an update and tell whetheror not a name is being transferred between owners.

In order to detect non-atomic transactions wemust expand our view to the prior value of a namebeing updated. Certainly if the value does notchange then the transaction is simply renewing thename, not transferring it. However considering allother transactions to be name transfers is far tooconservative of a criterion. Users freely update thevalues of names whenever information in them be-comes outdated.

Although there doesn’t seem to be a way to de-tect non-atomic name transfers generally, there isan important subclass of these transactions whichcan still be detected — transfers from squatters toregular users. In the previous section we discussedour detection of squatters in the block chain whichproduces a list of values which with a high proba-bility belong to squatters. Detecting transfers fromsquatters by finding names that change from one of

13

these values to a value outside this set gives us astrategy to detect transfers.

We employ an additional criterion to eliminatefalse positives to tighten our upper bound. If aname’s value includes an info or email field and thatstays the same in the updated value we can assumethis is simply an update by the squatter.

Applying this analysis at various squatter thresh-old values, we see that the total number of squatter→ non-squatter transactions detected holds at ap-proximately 250 transactions. We emphasize thatthis value is likely an upper-bound since our cri-teria for reducing the number of transactions werequite conservative.

To summarize, we would expect that given thehigh percentage of squatted .bit names, if there isa flourishing secondary market it would be domi-nated by sales from squatters to regular users. Yetwe are able to upper bound the number of suchtransfers to about 250, a tiny fraction of the numberof squatted names. Further, even though Namecoinsupports a secure way to transfer names, we findstrong evidence based on known tools supportingthis functionality that its usage is very low.

6 Exploring namespace designchoices

Throughout this section we will refer to the con-cept of the decentralized algorithmic agent that weintroduced in Section 3. Several of the options weexplore will require this agent to implement rathercomplex algorithms. We will not directly addressthe question of practical feasibility of complex de-centralized agents. We note, however, that based onproposed designs, these agents can be surprisinglypowerful; we refer the reader to [6, 21, 22].

6.1 Control of names

At any point in time, each name is either con-trolled by some user or is unclaimed. In the lattercase, it can be considered to be owned by the de-centralized agent encoded into the cryptocurrency,and is on the primary market. Any user can attemptto purchase any name on the primary market. Wewill return later to the question of how the name ispriced.

When a name is controlled by a user, how strongis that control? We can consider a hierarchy of in-creasingly weaker forms of control.

1. Control lasts forever and names cannot betransferred. It is straightforward to design a names-pace in such a way that names are non-transferable(in Namecoin, it would be a matter of requiring theinput and output of a NAME_UPDATE transactionto have the same address). Making names non-transferable would lock authority to update to thevalue restricted to the key used to first register thename. Such a system could deter speculative squat-ters because a speculator would not be able to sella name to another individual. While it would bepossible to transfer the private key that controls aname, the user receiving it would have no crypto-graphic assurance that the original owner does stillposses a copy of the key. On the other hand squat-ters who wish to censor names or simply damagethe system would be undeterred by the inability totransfer names.

As we noted in Section 3, utility functionsare time-varying, so a technical restriction againstname transfer goes against the logic of the market.It is possible that most names would be controlledby squatters who act as dealers and lease namesto users. Essentially this would make the systema hybrid between a centralized and a decentralizednamespace.

2. Control lasts forever except if the user choosesto transfer or sell the name. This approach is easyto understand as it is the most similar to physicalproperty. A practical problem with this approach isthat if a user loses her key, any names controlledby that user or key are lost forever. This may alsohappen if a user leaves the system, but this prob-lem can be alleviated by having the primary marketagent buy back names from users. This incentivizesthe user to give up the name before leaving the sys-tem even if she can’t find a seller for it. The agentessentially acts as an automated market maker.

3. Names expire after a fixed period, except ifthe user renews it. This is a practical choice thatavoids the problems pointed out above, especiallyif the renewal fee is very small compared to theprice of the name on the primary market. We ex-pect that a rational user will keep renewing a nameshe controls unless her utility drops to near-zero, orshe loses the associated private key and therefore

14

can’t update the name. If the renewal fee is sub-stantial, this becomes similar to a lease instead ofownership. The renewal fee is paid to the agent.

Finally, the agent may pay the user if she lets hername expires, returning her original fee to her. Thisis analogous to a deposit.

4. Names always expire after a fixed period andreturn to the primary market. Seizure or censor-ship becomes easy. Additionally, if we imagine thatnames appreciate in price by being used, just asland that is developed increases in value, this dis-incentivizes users from putting names to use sincethey have no expectation of being able to hold onto them. So this model is clearly inappropriate forapplications like domain names, but perhaps usefulin other contexts.

5. Control over names may be preempted byother users. This is an idea that has been proposedseveral times in the context of Namecoin, allowingusers to either force a name to return to the primarymarket or even directly acquire it by paying the afee to the agent and/or the current owner. This is in-tended to alleviate squatting, but it is hard to imag-ine this approach being superior to a functioningsecondary market. On the other hand, the down-sides are clear: seizures are now possible, and asbefore, uncertainty over future ownership may dis-courage legitimate use.

6.2 Markets and feesPrimary market: auctions vs. algorithmic

pricing. There are essentially two choices for theprimary market: auction and algorithmic pricing.Auctions are appealing, but there are practical prob-lems due to the infinite number of names. For ex-ample, let’s say an auction for a name is triggeredwhenever any user expresses an interest in buyingthat name. Since there are a potentially infinitenumber of names that a user is interested in, shewould have to be able to participate in an auction atany time, which is a problematic assumption. Al-ternatively, names could go up for auction at fixedtimes, but this also has practical downsides.

On the other hand, names can be priced algo-rithmically. This is more applicable for applica-tions like domain names than for personal names-paces. In the former case the utility of a name isless dependent on the user and therefore easier toprice based on publicly available data. Several fac-

tors based on publicly available data can be incor-porated into the pricing model: name length, fre-quency of the name (treated as a word) in text foundon the web, traffic rank of the corresponding .comdomain, and so on. Pricing can also vary with time;a blended model between auctions and algorithmicpricing would see initial prices decided algorithmi-cally which decline steadily over time in a form ofDutch auction. Again the challenges in implement-ing this are practical: incorporating data external tothe block chain into the computation of distributedagents is possible, but very complex and has notbeen successfully demonstrated in practice. If thesecondary market is implemented within the sys-tem (see below), then the agent has access to pric-ing data for other similar names as well as for thesame name if it was previously sold on the sec-ondary market.

There is an interesting technical limitation ofagents which affects algorithmic pricing. Since theagent doesn’t have private storage, an adversarialnode in the peer-to-peer network can intercept auser’s request to the agent to purchase a name, andtry to purchase that name ahead of the user, per-haps in the hope of turning around and selling itto the user. This is analogous to front running. Infact, front running is a problem in the current DNSas well, carried out by intermediaries that providedomain registry search services [23]. Fortunately,in the cryptocurrency context there’s a simple cryp-tographic solution: the user first presents a sealedbid to the agent (here it is the name that needs tobe sealed, not the price, which is public); after thismessage is confirmed in the block chain, the user(from the same address) reveals the name. Now theadversary cannot front run the user because he can-not spoof messages (transactions) from the user’saddress.5

Namecoin uses a simple model of a flat fee for alldomains that varies with time (which we can thinkof as a trivial case of algorithmic pricing).

Secondary market. As long as the technical ca-pability to transfer names exist, we would expecta secondary market to develop without any furtherdesign support. In addition, the ability to transfer

5This is the approach used in Namecoin, and the reasonwhy NAME_NEW and NAME_FIRSTUPDATE need to be dis-tinct operations separated by a 12-block waiting period, as de-scribed in Section 2.3.

15

names and payment in a single atomic transactionallows parties to transact without a trusted interme-diary. This is straightforward to implement techni-cally as we discussed in Section 5; Bitcoin and mostaltcoins including Namecoin support it.

However, there are benefits to the capability topost bids and offers on the block chain as well asexecute trades. First, as a practical matter, whencryptocurrencies are in the bootstrapping stage, ex-changes may not develop or may be fragmented.We see this problem with Namecoin. Secondarymarkets for DNS names are also fragmented. Afragmented or non-existent secondary market mayin turn inhibit adoption of the namespace. Inte-grating an exchange (implemented, of course, ina decentralized form) may prevent this problem.As an interesting historical aside, early versionsof Satoshi Nakamoto’s Bitcoin code contained ex-change functionality in prototype stage, but thiswas never rolled out [24]. Second, as mentionedabove, executing trades via the block chain allowsthe agent direct access to price data, and this mayhelp with algorithmic pricing. Finally, integratingan exchange allows shaping the secondary market,for example, by charging a fee for trades. As men-tioned earlier, it is technically feasible to deter pri-vate trades; this would force or incentivize trades tohappen through the integrated exchange.

6.3 The agent’s financesIn a centralized namespace, the owner of the

namespace has a clear goal of maximizing revenuefrom name sales. In a decentralized system, this istypically not a meaningful goal. After all, the agentis not a real-world entity. How, then, should theagent handle its finances?

Our first simplifying observation is that there isno point in the agent holding on to any funds —even if it needs to buy names from users, it cansimply print money (introduce new coins into thesystem) as necessary. Of course, from a practicalperspective it may be easier to have the agent storefunds; this corresponds to the proposal in Name-coin to treat registration fees as deposits and to holdthem in “escrow” [25]. Conceptually, however, wecan get rid of this option.

That leaves two options. The first is to distributeits revenue to miners, in proportion to their hashpower at the time of the transaction. This is techni-

cally straightforward to do by structuring paymentsas transaction fees to be collected by the miner whofirst mines a block containing that transaction. Theother option is to “burn” the coins representing thepayment, i.e., mark them as permanently unspend-able. This is also technically trivial. Assuming thatthe market capitalization of the currency is unaf-fected by burning some of it, it has the effect of dis-tributing the agent’s revenue to all holders of thecurrency in proportion to their holding. Both ofthese appear to be reasonable options, and Name-coin has used both; it is not clear which is betterin terms of incentivizing the long-term growth andsecurity of the system.

7 Related WorkHere we discuss attempts besides Namecoin at

decentralized cryptocurrency-based namespaces ordomain-name systems and more broadly technolo-gies that utilize the block chain.

Bitshares is another altcoin that includes propos-als for a namespace as one of its goals [26]. Emer-coin recently emerged as a Namecoin competitor[27].

More broadly, the ability to publish messagesto the block chain immediately allows a variety ofapplications. Physical property, shares of stocks,bonds, or any other real asset can be digitally repre-sented on the block chain. Overlay protocols suchas Mastercoin and Colored Coins specify a syn-tax and semantics for such digital representations[28, 29]. CommitCoin allows for putting hash com-mitments on the Bitcoin block chain in order totimestamp data in a trustless manner [30].

There are a number of more complex applica-tions that require additional primitives. Financialderivatives are contracts whose value depends, insome mutually agreed-upon way, on the price (ormovements in price) of an underlying asset. Im-plementing derivatives of digital assets, then, re-quires user-defined logic (or scripts) for transac-tion validation. This can be accomplished via analtcoin with a flexible scripting language such asEthereum [21]. Furthermore, since derivatives de-pend on prices, scripts that implement them requireaccess to price feeds as input. Otherwise, it requiresa trusted third party (known by a Bitcoin address)to regularly publish suitably encoded, signed price

16

statements reflecting external reality. These can bepublished directly to the block chain or distributedoff-chain and only added to the block chain whenneeded to redeem an asset. More generally, suchentities could publish any data feed representingnews or other events.

Bitcoin can act as a platform for fair secure mul-tiparty computation [31, 32, 33]. These are SMCprotocols augmented with Bitcoin operations, e.g.,a payment from one participant to another, or a de-posit.

Finally, a set of related ideas known as decen-tralized autonomous organizations (among severalother names) has stirred considerable excitementin the community recently. These combine severalprimitives discussed above — digital assets, long-lived scripts implementing arbitrary logic govern-ing those assets, data feeds, and out-of-band com-munication. Some proposals for DAOs incorporatehuman input in various forms: one is a decentral-ized agent farming out computationally intractabletasks to humans [34]. Another is voting by share-holders of decentralized agents to enable modifica-tions to the logic (i.e., script).

8 Discussion and ConclusionOur empirical analysis of Namecoin and explo-

ration of the design space reveal several potentialmechanism design weaknesses. First, Namecoin’sfees are far too low to deter squatters. The systemutilizes neither an auction nor algorithmic pricingthat might help price names near their market value.Worse, users who paid a high network fee in theearly period and who wish to leave the system haveno way to recoup any of their investment by return-ing the name to the primary market.

These problems are exacerbated by the lack ofa functioning secondary market. Buying a squat-ted name, even if contact information is availableon the block chain, is a cumbersome manual pro-cess. There is no way to, say, search for all namesavailable for sale matching a given string and be-low a specified price limit. Namecoin does not in-tegrate an exchange into its core functionality, norhave Namecoin developers chosen to build and pro-mote one outside the system.

Is a decentralized namespace for domainnames viable? Even with a hypothetical system

where the above weaknesses are fixed, it’s not clearthat it would be a viable platform for a decentral-ized DNS. Namespaces are a solution to the prob-lem of mapping names to values. However, in adomain name system, the problem that needs to besolved is to map entities — legal entities, brands, oridentities — to addresses/values.

Naturally, mapping entities to names (or directlyto values) is not a purely technical problem, but re-quires human judgment. In the traditional DNS,arbitration based on trademark law is a mecha-nism to prevent names that are confusingly simi-lar from being controlled by different entities. Thisis augmented with Extended Validation certificates,which, when used, establish the legal identity of thename owner. With these mechanisms in place, theuser must still provide a name to the system, but atleast she can then verify that it corresponds to thecorrect entity she had in mind. This type of verifi-cation is much harder to incorporate in a decentral-ized system. We are not aware of any designs fordecentralized systems that attempt to do so.

If such mechanisms are not developed, can de-centralized namespaces for domain names be viableat all? Or will they depart so far from user expecta-tions as to be unusable?

Other solutions for usability might be possible.Web search engines are used in practice as a wayof mapping entities to names. Indeed, such “nav-igational queries” are one of the primary ways inwhich people use search engines.6 Navigationalqueries are about equally viable in centralized anddecentralized systems. Presumably, using searchengines and following links from other sources (in-cluding bookmarks) will allow a user to graduallymemorize an entity→ name mapping.

Of course, if users always used these nagiva-tional aids and relied on them entirely to find thecorrect name, then those names don’t have to behuman-memorable or user-chosen, so one doesn’tneed a namespace at all. Indeed, .onion domainsforce users to rely on navigational aids since namesare public keys and can’t be freely chosen by users.Anecdotally, however, it is clear that this results inpoor usability and memorable names would be animprovement.

6Bing reports that about 30% of queries are navigational[35].

17

We remain neutral on the question of whethera decentralized namespace for domain names canbe viable. But the human factors we discussed docomplicate the mechanism design question. In Sec-tion 3 we proposed utility maximization as a (straw-man) goal of the mechanism, and suggested thatan auction would satisfy this goal. However, in anauction-based system, it may turn out that an adver-sary interested in phishing has a higher utility for(say) bankofamerica.com than Bank of Amer-ica does. It is not clear how to design a mechanismthat will discourage such outcomes.

Comparison between .bit and OneName. Incontrast to the .bit subspace, the online identity ser-vice, OneName, has a very large user base. Wefound that after limiting the number of name/valuepairs to only those with unique, well formed entries(using the strategies listed in section 5) OneNamehas roughly 20,000 pairs, which dwarfs the 1000or so .bit domains. It is too early to tell whether ornot these users are putting their OneName identitiesto any real use, but at least in terms of registrationnumbers, interest appears to be high.

Perhaps the biggest reason for this is that whilescarce, OneName names are not nearly as valuableas domain names, and so it is far less important toget the mechanism design right, or have any mech-anism at all. Unlike domain names that must beremembered by humans, users typically find One-Name identities through links from other social me-dia services or by searching for the individual’s realname.

A second reason is that OneName benefits frombeing a centralized service on top of a decentralizedprotocol, OpenName (which, as of this writing, isimplemented on top of Namecoin). If a name issquatted, a typical user who wants that name mightnot even know how to contact the squatter becausethey are trying to register a name through the One-Name website which doesn’t facilitate this process.While a user could technically interact with the ‘u/’subspace of the block chain directly, most One-Name users don’t.

The .bit subspace, on the other hand, suffers fromthe lack of any centralized service providers cou-pled with the poor usability of the client software.A new user faces many significant hurdles in regis-tering a name. The first step is acquiring a Name-coin client which requires downloading, verifying,

and storing the entire block chain, which is cur-rently about 1.6 GB. Then she must acquire NMC,which requires connecting the user’s wallet on acryptocurrency exchange (which supports Name-coin) to her bank account. In our experience, thereis a 3-day wait after registering with an exchangeand being allowed to transfer funds. Now the useris finally ready to register names, but she must alsoremember to update names every 250 days or runsoftware in the background that will automaticallyhandle this.

In conclusion, designers of decentralized names-paces must pay careful attention to mechanism de-sign to deter squatters and facilitate a healthy sec-ondary market. Further, the usability of the overallecosystem, which includes not just users who ownnames but the applications that utilize the names-pace for web browsing or other tasks, is paramount.Finally, a hybrid model of centralized servicesthat utilize an underlying decentralized platform isworth considering.

Acknowledgement. We would like to thank EdFelten and Muneeb Ali for helpful discussions andfeedback. This work was supported in part by NSFGrant CNS-1421689.

References[1] Paul Mutton. WikiLeaks.org taken down

by US DNS provider. URL http://news.netcraft.com/archives/2010/12/03/wikileaks-org-taken-down-by-us-dns-provider.html.

[2] Wikipedia. Zooko’s triangle, . URLhttp://en.wikipedia.org/wiki/Zooko%27s_triangle.

[3] Aaron Swartz. Squaring the triangle: Secure,decentralized, human-readable names. URLhttp://www.aaronsw.com/weblog/squarezooko.

[4] Satoshi Nakamoto. Bitcoin: A peer-to-peer elec-tronic cash system. URL https://bitcoin.org/bitcoin.pdf.

[5] appamatto. Bitdns and generalizing bitcoin.URL https://bitcointalk.org/index.php?topic=1790.0.

[6] J Bonneau, J Clark, E Felten, J Kroll, A Miller,and A Narayanan. On decentralizing predictionmarkets and order books. In Workshop on the

18

Economics of Information Security, 2014. URLhttp://weis2014.econinfosec.org/papers/Clark-WEIS2014.pdf.

[7] Domain name specification, 2015. URL https://wiki.namecoin.info/index.php?title=Domain_Name_Specification.

[8] khalahan. Nmcontrol. URL https://github.com/khalahan/nmcontrol.

[9] Freespeechme website. URL http://www.freespeechme.org/.

[10] Greg Slepak. Dnschain. URL https://github.com/okTurtles/dnschain.

[11] Opennic project. URL http://www.opennicproject.org/.

[12] Keybase. Keybase. URL https://keybase.io/.

[13] Luke A Walker. Icann’s uniform domain namedispute resolution policy. Berk. Tech. LJ, 15:289,2000.

[14] William L Silber. Marketmaker behavior in anauction market: an analysis of scalpers in futuresmarkets. The Journal of Finance, 39(4):937–953,1984.

[15] John R Ottensmann. Urban sprawl, land valuesand the density of development. Land economics,pages 389–400, 1977.

[16] Atila Abdulkadiroglu and Tayfun Sönmez. Match-ing markets: Theory and practice. In Advancesin Economics and Econometrics (Tenth WorldCongress), pages 3–47, 2013.

[17] Daniel. Proposal: Domains should beregularly auctioned. URL https://forum.namecoin.info/viewtopic.php?f=11&t=2003.

[18] Roger Dingledine, Nick Mathewson, and PaulSyverson. Tor: The second-generation onionrouter. Technical report, DTIC Document, 2004.

[19] Juan Pablo Timpanaro, Chrisment Isabelle, andFestor Olivier. Monitoring the i2p network.2011. URL https://hal.inria.fr/hal-00653136/document.

[20] ANTPY Github. Bitcoin github com-mit history. URL https://github.com/bitcoin/bitcoin/commit/5253d1ab77fab1995ede03fb934ed.

[21] Ethereum white paper, 2015. URLhttps://github.com/ethereum/wiki/wiki/White-Paper.

[22] Bitcoin Wiki. Agents. URL https://en.bitcoin.it/wiki/Agents.

[23] Wikipedia. Domain name front running, .URL https://en.wikipedia.org/wiki/Domain_name_front_running.

[24] phelixbtc. Bitcoin github. URL https://github.com/phelixbtc/antpy.

[25] Namecoin Forum. Idea for better fee struc-ture. URL https://forum.namecoin.info/viewtopic.php?p=6653&sid=2cf37d245bbc611a8d93ad6ac23b9982.

[26] .p2p (bitshares dns), 2015. URL http://wiki.bitshares.org/index.php/.p2p_%28BitShares_DNS%29.

[27] Emercoin, 2015. URL http://emercoin.com/.

[28] Mastercoin protocol specification, 2015. URLhttps://github.com/mastercoin-MSC/spec.

[29] Meni Rosenfeld. Overview of colored coins,2012. URL https://bitcoil.co.il/BitcoinX.pdf.

[30] Jeremy Clark and Aleksander Essex. Commitcoin:Carbon dating commitments with bitcoin. In Fi-nancial Cryptography and Data Security, pages390–398. Springer, 2012. doi:10.1007/978-3-642-32946-3_28.

[31] Marcin Andrychowicz, Stefan Dziembowski,Daniel Malinowski, and Lukasz Mazurek.Secure multiparty computations on bitcoin.In Security and Privacy (SP), 2014 IEEESymposium on, pages 443–458. IEEE, 2014.doi:10.1109/SP.2014.35.

[32] Iddo Bentov and Ranjit Kumaresan. How to usebitcoin to design fair protocols. In Advancesin Cryptology–CRYPTO 2014, pages 421–439.Springer, 2014. doi:10.1007/978-3-662-44381-1_24.

[33] Ranjit Kumaresan and Iddo Bentov. Howto use bitcoin to incentivize correct compu-tations. In Proceedings of the 2014 ACMSIGSAC Conference on Computer and Commu-nications Security, pages 30–41. ACM, 2014.doi:10.1145/2660267.2660380.

19

[34] Vitalik Buterin. Daos, dacs, das and more:An incomplete terminology guide, 2014. URLhttps://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide/.

[35] Bing blogs: Making search yours, 2011. URLhttp://blogs.bing.com/search/2011/02/10/making-search-yours/.

20

A List of significant .bit domainsBelow is a list of names counted towards the last en-

try in Table 2. These domains were determined by theproccess described in Section 4.

• alt-freedom.bit

• bangkokgroup.bit

• bitcoinpl.bit

• bitcoinquotes.bit

• carnicominstitutemirror.bit

• changepurse.bit

• columbo.bit

• darkfur93.bit

• dcinvestments.bit

• dealing.bit

• deathrowdemocracy.bit

• dot-bit.bit

• dotbitkittypix.bit

• feens.bit

• hewgill.bit

• hosting.bit

• kk-cabrio.bit

• lapan.bit

• medicinalgenomics.bit

• megabrutal.bit

• michail.bit

• mikeward.bit

• namecoin-test-suite-1.bit

• onemillionpixels.bit

• peterboswell.bit

• rmgx.bit

• tuler.bit

• wikimouto.bit

21