Namecoin: A Decentralized Trusted Base

Introduction

I’ve been thinking a lot about transport-dependent DNS settings (BIND, http, tor, and i2p) and the architecture the original Domain Name System and applied encryption. After long talks with Ryan-C and Mark of EasyDNS, I believe we need to recast Namecoin’s purpose as a decentralized trusted base which offers secure delegation, not as a generic key->value datastore.

A Trusted Base

The real innovation offered by the blockchain is the ability to have trusted transactions between untrusted parties. Public-key cryptography offered a similar breakthrough 40 years ago: trusted communication across untrusted channels. However, public-key cryptography comes with a severe amount of overhead and it is NOT used to encrypt the bulk of the communications but only the initial symmetric key exchange.

A Terrible Datastore

By extension, the additional overhead required to store data on the blockchain makes them slow and costly generic key->value data stores. They also do not offer any protections for their users, whether it is Tahoe LAFS over I2P, Freenet, or a PHP upload script on a Tor hidden service, Namecoin is simply a lousy choice for publishing material that runs afoul of the powers that be.

Domain Name System

Even ignoring the generic data storage use case, Namecoin isn’t very good at storing DNS entries either. As antiquated as the domain name system is, John Postel put together an architecture that has scaled from a few dozen machines to a few billion over the past 30 years. The key to this scaling is delegation, Verisign and other organizations that manage root zone files for TLDs do not store full blown DNS entries, they store links. The root zone files for .com is 9.5 gigs of the following:

NS2.EXERTIVE AAAA 2001:db8:85a3:8d3:1319:8a2e:370:7348
NS3.EXERTIVE A 68.180.194.243
NS3.EXERTIVE AAAA 2001:db8:85a3:8d3:1319:8a2e:370:7348
NS4.EXERTIVE A 68.180.194.243
NS4.EXERTIVE AAAA 2001:db8:85a3:8d3:1319:8a2e:370:7348
NS1.CYBERTX A 98.136.63.35
NS2.CYBERTX A 178.65.210.178

Public Key Infrastructure

However, what of the case of id/? Again, storing the actual public keys in the blockchain turns out to be a terrible idea. A proper keyserver must be able to store an arbitrary amount of material. Each id/ would come with a signing key and an encryption key, both of which can be an arbitrary length. But we must also store child keys, email addresses, endorsements from key holders, an image of the owner, etc, etc.

Great for Secure Delegation

In every cryptographic trust system we find the use of a master signing key (a key signing key, a root certificate, etc, etc) which is used to sign child keys. The best practices for one of the oldest public key systems, PGP, is identical to that of all the others: create a master key which is stored on an air-gapped machine that then signs one’s everyday keys. Others only need to trust the master key to validate which child keys are still valid.

This is known a well-known design pattern called secure delegation and it fits perfectly with the capabilities of Namecoin. Every single proposal for Namecoin comes down to three elements: a human meaningful name (URN), a link to an authorized server (URL), and a public-key hash.

Other than convenience items for short DNS entries, such lists for translate/DNAME, alias/CNAME, and import statements, d/ records should be restricted to an ns and tls arrays. The same goes for id/: public key hashes, website and email links, and (for convenience) short ECC public keys.

Why Does This Matter?

While Namecoin is a key -> value datastore, this ignores the reality that blockchains are databases that accommodate small pieces of information that change on the order of minutes to hours. The strengths Namecoin and our datastore is most efficiently communicated as a decentralized trusted base. This mental model better reflects Namecoin’s strengths and weaknesses, leading to better architectural choices both internally and externally.

Architectural Choices

I came to this conclusion while trying to work out additions to the current d/ record specification for HTTP transport (aka frame resolution, jsDNS, Speech.is, etc). I won’t get lost in the details of that process here but it was clear that the right solution was to use a nameserver.

But this became a recurring theme:

  1. How should we handle a server that supports transport over DNS, HTTP, Tor, and I2P? A transport neutral specification would help but there would always be transport specific options that would not only complicate matters but also bloat the record.  It’s better to just point to a transport specific nameserver.
  2. How should a registrar handle their customers DNS entries? Nameservers!
  3. How should /id handle large keys? Keyservers!

Brain Dead Ideas

Some crank came onto the forum recently to announce a new service: NamecoinFiles.org. This idiot thinks that the world needs a service which specializes in uploading files the Namecoin blockchain. We’ve also had an idiot come onto IRC who wanted to upload an archive of The Pirate Bay to the Namecoin blockchain.

Now, there is no way the blockchain would ever become a real platform for distributing such materials. We’ve checked with lawyers, and as long as the price is high enough we won’t get into any trouble either. Lightweight resolvers can also shed such material, so their impact is limited to being one-off pranks.

However, we don’t need these headaches. I think that as long as we brand Namecoin as a generic, censorship resistant key->value datastore, these sorts of idiots will keep popping up.

Ramifications

Branding

We should rebrand the website and altering our internal and external communications to emphasize the trusted base model is a fairly logical next step.

Simplification of Specifications

As noted above, I believe that records stored on the block chain should be trimmed to a URN, URL, and public-key hashes and a minimum number of convenience fields. Each transport is free to have arbitrarily complex records which are retrieved each namespaces equivalent of a nameserver.

Changes to Record Size

Trimming records to a URN, URL, and hash drastically reduces the size required for each record. There was already an accidental 512 byte limit on record sizes, but we’ve nixed plans to increase the size and keep it at 512 bytes.

Take a hypothetical domain name record consisting of an array of nameservers accessible over plain-old-DNS (PODS), Tor, and I2P plus two hashes of the public keys:

"ns": [
  "ns1.example.com",
  "ns2.example.com",
  "suw74isz7wqzpmgu.onion",
  "7e3e1add61049555.onion",
  "ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p",
  "udhdrtrcetjm5sxzskjyr5ztpeszydbh4dpl3pl4utgqqw2v4jna.b32.i2p"
],

"tls": {
  "sha2": "a948904f2f0f479b8f8197694b30184b0d2ed1c1cd2a1ec0fb85d299a192a447",
  "sha3": "9103cd7811eb11c25788b5ce87b55ec10ee87e86d0bf4d383da139015d39a924"
}

The above clocks in at <400 bytes. Domains that need more can use an import statement.

2 Responses to “Namecoin: A Decentralized Trusted Base”

  1. nickik February 2, 2015 at 1:36 pm #

    Hi,

    Thanks for your Blogposts. Have you looked at the Dename system? What do you think about it?

    https://github.com/andres-erbsen/dename
    https://github.com/andres-erbsen/dename-writeup/blob/master/dename.pdf

  2. JJ February 21, 2015 at 7:21 am #

    +1

Leave a Reply