Jump to: navigation, search


Warning: I found this page because a new contributor asked about it. As far as I can tell it was entirely written by one person who is no longer active in the community, without any input from anyone else and for that matter without even informing anyone that this page existed. At first glance, the vast majority of the stuff here is just plain wrong and does not represent the current or former position of Namecoin. I will be going through official channels to delete this page in the near future, but in the meantime assume that everything here is false, because you won't be far off. There is some ongoing effort to produce an actual roadmap. Cheers. --Biolizard89 (talk) 12:51, 30 January 2016 (UTC)


Namecoin is the reference implementation of the Namecoin protocol. It is currently based on an older Bitcoin codebase but it receives regular security fixes and minor enhancements. We attempted to migrate to Libcoin in 2014 but we are now embarking on a reimplementation based on Bitcoin mainline.

v 03.80

  • Dust spam fix
  • UI enhancements
  • Misc. fixes

v 1.0

  • Reimplementation based on mainline Bitcoin.
    • Use Devcoin merge-mining code.
    • Port Isracoin name operations code.
  • TravisCI integration

v 1.1

  • Gitian builds
  • UXTO?
  • SPV?


Libcoin has full support for all Namecoin read operations and a UTXO mode with an installation size that is ~600 megs uncompressed and ~200 megs with filesystem compression. While we had planned a full Libcoin rebase the upstream repo was less-than-stable and the miner and wallet code quality was subpar. However, Libcoin is an excellent choice for application developers looking for a lightweight client.

Namecoin edition v 1.0

  • Overhaul repo
    • Maintain stable version using TravisCI integration and unit testing
    • Nighty uploads
    • Namecoin lite-mode by default, no command line switches
  • Namecoin specific documentation


NMControl is the chosen middleware for Namecoin, offering performance enhancements, a plugin-in architecture, and a python environment for extending the functionality of namecoind and libcoind.

v .9

  • Fix licensing
    • Get confirmation from Khal and Pagel
    • Rewrite (we were considering a move to Python 3....)
  • Port Unbound DNS server
  • Port NamecoinToBind for zone exporting
    • DNS RFC conformance tests
  • Port a standard RPC library
    • Barrister-RPC – generates client libs in 5 languages and documentation.
    • Django RPC library supports SMD.
  • id/ functionality?
    • Exporting OpenID standard?
    • GPG PKI lookups?

v 1.0


FreeSpeechMe provides browser and system-level .bit resolution. FSM adds it's own certificate to the system's browsers and checks incoming .bit connections against the certificate fingerprints specified in their .bit DNS record. If the correct TLS certificate is present, FSM replaces the cert with it's cert, which is trusted by the browser. IF their is a mismatch, it replaces it will an untrusted certificate. Even though FSM replaces the TLS certificate, the connection is as safe (if not more so) than if the certificate were trusted by the browser directly and never replaced.

Browser Add-On

The browser add-on is a fork of Convergence written by Moxie Marlinspike. While Namecoin solves the trust issues addressed by Convergence, it is still very high quality certificate checking add-on. The browser add-on can use a system-wide Namecoind installation or package it's own.

v 0.5

  • Package NMControl & Libcoind UTXO
    • Detect local libcoind or namecoind install
  • UI Change
    • Remove notary UI (see above)
  • Merge with bit.namecoin.org

v 1.0

  • SPV mode
  • Tor interop
  • Test coverage
  • Gitian builds
  • HTTPS-Everywhere integration
    • Potential collaboration with Tor/I2P

Stand Alone

FSM standalone is a XULRunner version of the Firefox add-on but it still works for all browsers.

v 0.5

  • Package NMControl & Libcoind UTXO
    • Detect local libcoind or namecoind install
  • Merge with bit.namecoin.org
  • TLD-specific DNS lookups
    • Linux
    • Windows

v 0.9

  • TLD-specific DNS lookups
    • Mac
  • Test coverage?
  • Gitian builds?

v 1.0

  • Proxy detection (Tor, etc)
  • Gui installer

Legacy Interop

The Speech.is team is heading up interoperabiltiy with the traditional DNS system, enabling ubiquitous to access .bit domains without the need for special software or altering system settings. The goal is to solve the chicken/egg problem inherent in adoption of the .bit TLD: universal access to .bit sites will fuel demand and increased censorship will push browser and operating system vendors to adopt native resolution that is inherently more resistant to censorship, more secure, and privacy preserving.

Fundamentally, this requires a downgrade from the trustless nature of the blockchain, but we intend to make it as censorship resistant and secure as possible given the constraints. This is not desirable, but the percentage of total internet traffic running across IPv6 remains in the single digits despite IPv6 being 30 years old. Any engineer worth their salt understands the necessity of backwards compatibility.

Furthermore, outside attempts at providing backwards compatibility (DNSChain, OpenNIC, random .bit suffixes) have proven to be less secure, less censorship resistant, and less usable than traditional TLDs. Our architecture will ensure that .bit sites accessed through legacy DNS will be at least as secure as those native to the legacy DNS system, if not more so.

We will always push users and vendors towards native resolution. Whenever possible, links to sites on the DNS suffix and JS DNS will detect support for native resolution and forward users to the real .bit domains. Informational sites will advertise the FSM browser add-on and standalone FSM. If this system does not result in increased adoption of native resolution, then we will consider it a failure and shut it down.

Honestly, we are hoping that the "powers that be" will be stupid enough to try seize or block sites on the .bit suffix. It will raise awareness of the problem, increase end-user adoption of FSM, and push browser and operating system vendors to adopt native resolution.

Signing Backend

The legal rationale regarding the backend is based on Tor's directory servers: we are simply publishing public domain information (DNS records and zone files) and establishing trust using threshold encryption. Two publishers will be public but reside diffing legal jurisdictions. The remaining three publishers will operate anonymously behind Tor.

Warrant canaries make it highly unlikely that law enforcement would ever try interfere with the two public publishers. Even if both public publishers are forced to stop operating, the anonymous publishers can continue to publish and sign zone files and DNS records.

  • Record Signing
    • Threshold RSA 3/5 signing scheme.
      • Requires hiring a mathematician to implement an advanced form of threshold encryption that is compatible with DNSSEC. Even so, the total number of admins are restricted to 5 thanks to DNSSEC's 4k key length limit.
    • All admins must publish warrant canaries.
  • Hidden Resolvers/Signing Servers
    • All of the signing servers will be isolated via Tor.
    • All servers must utilize dedicated machines, no VMs.
    • All servers must utilize hardware security modules to isolate the signing keys.
    • 10 servers and HSM modules total.
      • Redundant server for each admin.
    • Document and automate (system image, shell scripts, ansible) system setup and configuration.
  • Public Publishing
    • DNS records (zone files and flat JSON records) will be published to Archive.org.
      • Free public-facing HTTPS server and Torrent tracker with support for mutable Torrents.
    • CC0 license.

Speech.is Web API

The Speech.is backend API offers a scalable REST API for retrieving Namecoin records. It is generic enough that many clients other than the Speech.is website may find it useful. CouchDB libraries essentially gives us "free" client libraries that can take advantage of CouchDB's syncing capabilities.

The backend API will receive updates to allow for signed JSON and a WebRTC based P2P architecture upgrade. It will continue to operate as long as it proves useful.

Front End

Speech.is was originally architected (see the speech.js section below) to handle specific legal issues that are not as relevant today as they were 2 years years go. In response the Speech.is team is "pivoting" and prioritizing a traditional DNS suffix. Compared to JS DNS (i.e. Speech.js) a DNS suffix supports a wider range of functionality.

The backend for both the JS DNS and the DNS suffix are largely identical and both will continue to operate in parallel. The Speech.is API also provides a highly scalable web API that can be used by generic services. We will continue to operate the Speech.is website as it may useful as a political/legal wedge issue in the future.

DNS Suffix

We will likely contract with EasyDNS for nameservers for the DNS suffix. We are attempting to purchase multiple, redundant "bit" domains in legal jurisdictions that do not have a history of domain name seizures, such as Switzerland and Sweden.

DNS Resolvers

We are hoping to eventually get universities and public DNS servers like Google DNS and OpenDNS to import our zone files. If we can afford the cost, we may pay EasyDNS to setup public DNS resolvers as well.


Speech.js is a reference implementation of a JavaScript DNS (JS DNS) and the Speech.is website is the canonical installation. JS DNS is a client-side JavaScript application that reimplements parts of the browser in Javascript (primarily DNS). A website serving speech.js enables navigation of .bit website in a way that is more secure than traditional web proxies and more censorship resistant than web proxies or DNS suffixes.

The Speech.is website operates primarily as a political wedge issue for nationwide blacklists and domain name seizures, as blacklisting speech.is#wikileaks.bit will not play well in the courts or the press. It also avoids running afoul of the DMCA and has excellent scaling characteristics, unlike web proxies.

However, public opinion has turned against DNS blacklists and the threat of their implementaion in the US (where blocking Speech.is might run afoul of the first amendment ) has largely subsided.

The Speech.is website and it's backend will continue to operate. The back end will receive some upgrades but most Speech.js development is on hold for now.

  • Partial Rewrite
    • Initial page load under 100ms from warm cache.
    • PouchDB backend moved to web worker.
    • Reduce resource usage (CPU & bandwidth).
    • Support full record parsing/resolution.
  • HTTPS support checking.
  • Babel.js/postMessage() handshake.
  • Add functional testing.
  • New URL with .bit.
v 1.0
  • Nameserver support.
  • IE and Safari support.
  • Mirroring for search bots.
  • Determine coverage, with eventual goal of an average 1.5x ways for an web admins to support Speech.is.
    • Cloudflare "app" would cover X% of websites.
    • A Wordpress plugin would cover X% of websites.
v 2.0
  • Native DHT support?
  • Bloomfliter updates.
  • Private IPs to dissuade IP-level blocking
v 3.0
  • Full-on browser-based proxy
  • JS SPV lite client.



  • Finish namecoin.org transition
    • Main website sever
    • TLS certs
  • Installation instructions
  • Port bit.namcoin.org and id.namecoin.org to a common namecoin.org codebase.
  • Move forum to Vanilla
    • Mainly to utilize the Q/A functionality
    • More advanced, soft moderation tools
  • Advertising
    • Initialize registrar list
    • Add referral code to exchange list
    • Advertising in forum


Research is core to our development process. Namecoin is a currency and changes must be carefully modeled before being implemented.

Alternative Difficulty Algorithms

Fundamental research about difficulty retargetting for blockchain-based systems. This includes building mathematical models of mining as a stochastic process and its control via a difficulty algorithm, as well as establishing properties of these models that can be proven mathematically. We aim to publish our results in a peer-reviewed journal and/or to present them at an international scientific conference.

  1. Basic mathematical properties of blockchain mining and how it behaves for various hashrate scenarios (constant, exponentially rising, sudden drop, ...) under the assumption of a fixed difficulty.
  2. Analysis of Bitcoin's difficulty-retarget algorithm: How certain statistical properties (e. g., expectation value and variance of the blockrate) behave under the above mentioned hashrate scenarios if we take difficulty adjustment into account.
  3. Analysis of an alternative diffculty-retarget algorithm to have some contrast, ideally one with continuous retargetting". It could be the one of Peercoin or Darkcoin, or a generic model.
  4. Optimisation of the algorithm's parameters or even design of an optimal algorithm based on desired properties (e. g., stability of the hashrate, fixed number of blocks produced in a given longer time interval, prevent orphans).
  5. Simulation of our models with both the existing algorithms and proposed alternatives based on historical hashrates.

Floating Price Proposal

Currently, altering prices for records requires a softfork and it affects all prices, regardless of the namespace. The fluid exchange rate makes this scheme far too rigid however creating a system that dynamically prices domains is surprisingly difficult. Previous proposals for price discovery mechanisms have determined prices based on domain purchasers or miners, but they all suffer from problems:

  • Voting systems suffer from the fact that purchasers always selecting a lower lower price.
  • Auction-style systems require a significant delay before the domain can be purchased and domain.
  • Allowing miners to arbitrarily set their domain price will simply lead to purchases waiting for a miner which accepts the lowest prices, driving prices to the bare-minimum operating costs. A specific price must be enforced across the network.

We've outline a proposal in which miners collectively vote on the domain price. by embedding a special data structure specifying their 'desired' name fee in their mined blocks. The price would be determined by a median of all votes within some window of blocks. Miners primary source of income is through transaction fees and block rewards; miners do not collect name_new fees. This leads to desirable voting incentives :

  • Names with too high of a cost will reduce overall purchasing leading to fewer transactions fees and devalued block rewards.
  • Names with too low of a cost devalues Namecoin's exchange rate due to squatting, which devalues collected tx fees and block rewards.

Initially, miners would simply have a static variable that would require manual intervention to change. However, miners could eventually incorporate real-time pricing data. However, we must simulate the consensus price mechanism, price caps, and rate limiting against Namecoin and Bitcoin exchange rates. We may also model potential attacks using game theory.

Quantification of Name Ownership

Squatting is Namecoin's bikeshed, a problem that gets a lot of attention but is easily solvable. However, we wish to quantify the squatting problem to ensure that anti-squatting measures disproportionately impact squatters.

We also need to optimize hybrid UTXO/SPV light clients that only store domains that they are likely to visit. Knowing which domains are controlled by squatters reduces the total number of domains that light clients must store locally. We also want to ensure the safety of our users, facebook.bit isn't in the control of Facebook and it should probably be entered into the PhishTank.

Furthermore, we want to get a baseline reading to gauge how difficult it is to anonymize domains. Even with transaction anonymity, we need to measure the entropy in the system before we can advise anyone on how long they should wait before purchasing their domain.