Namecoin is an experimental open-source technology which improves decentralization, security, censorship resistance, privacy, and speed of certain components of the Internet infrastructure such as DNS and identities.
(For the technically minded, Namecoin is a key/value pair registration and transfer system based on the Bitcoin technology.)
Bitcoin frees money – Namecoin frees DNS, identities, and other technologies.
What can Namecoin be used for?
- Protect free-speech rights online by making the web more resistant to censorship.
- Attach identity information such as GPG and OTR keys and email, Bitcoin, and Bitmessage addresses to an identity of your choice.
- Human-meaningful Tor .onion domains.
- Decentralized TLS (HTTPS) certificate validation, backed by blockchain consensus.
- Access websites using the .bit top-level domain.
- Proposed ideas such as file signatures, voting, bonds/stocks/shares, web of trust, notary services, and proof of existence. (To be implemented.)
What does Namecoin do under the hood?
- Securely record and transfer arbitrary names (keys).
- Attach a value (data) to the names (up to 520 bytes).
- Transact the digital currency namecoins (NMC).
- Like bitcoins, Namecoin names are difficult to censor or seize.
- Lookups do not generate network traffic (improves privacy).
Namecoin was the first fork of Bitcoin and still is one of the most innovative “altcoins”. It was first to implement merged mining and a decentralized DNS. Namecoin was also the first solution to Zooko’s Triangle, the long-standing problem of producing a naming system that is simultaneously secure, decentralized, and human-meaningful.
2019-08-25 As I’ve discussed before, Namecoin is using Tor’s rbm-based build system for our various Go projects, such as ncdns and ncp11, in order to reduce the risk of supply-chain attacks. Naturally, one of the important ways to test a reproducible build system is to build a binary twice in a row and see if the hashes are the same. If the hashes don’t match, then tools like Diffoscope can be used to figure out what the source of the reproducibility failure is. Now that Namecoin’s usage of rbm is reasonably stable (i.e. working binaries are produced for most of Namecoin’s software now), it’s a good time to look into how reproducible our binaries are.
2019-08-15 We’ve released ncdns v0.0.9.2. List of changes in v0.0.9.2:
2019-08-14 One of the lesser-known dirty secrets of the ncdns codebase  is that it relies on an unmaintained fork of Conformal’s btcd, which dates back to 2015. Specifically, ncdns uses a fork of the JSON-RPC client from btcd in order to query Namecoin Core, ConsensusJ-Namecoin, or Electrum-NMC. Why did Namecoin not find upstream btcd to be sufficient?
2019-08-06 One of the many pieces of witchcraft that Namecoin’s TLS interoperability requires is the ability to splice a signature into an X.509 certificate without otherwise modifying the certificate. Unfortunately, while the Go standard crypto library is generally quite pleasant to use (and is certainly better-designed than most other crypto libraries such as OpenSSL), the functions relevant to splicing a signature are not exported. This is understandable, since it’s not functionality that most users have any need for. However, since Namecoin does need that functionality, my only option back when this code was being written was to fork the
crypto/x509 package from Go’s standard library.
2019-07-30 In September 2018, I published a case study about centralized inproxies and how they can cause security dangers even to competent users who think they’re using a decentralized system. Although my article wasn’t targeted at any particular entity (like all case studies, it uses a specific entity to make generalizations about a wider field), the case study used OpenNIC’s inproxy as an example. (The fact that OpenNIC ended up as the example isn’t due to any fault of OpenNIC, it’s simply that the sysadmin mentioned in the case study happened to be an OpenNIC user.) In December 2018, PRISM Break maintainer Yegor Timoshenko (who is a friend of Namecoin) independently raised similar security concerns about OpenNIC’s Namecoin inproxy, commenting in PRISM Break’s Matrix channel “i’m not too happy we recommend dns servers that resolve .bit for users, it seems to be nearly as much helpful as resolving .onion” and subsequently proposing that PRISM Break avoid recommending DNS services that include that kind of functionality.
2019-06-18 ncp11 is now working (both positive and negative TLS certificate overrides) in Tor Browser for Windows. It turned out that the only things keeping it from working properly once it built without errors were a couple of GNU/Linux-specific file path assumptions, both of which were quite easy to fix.
2019-06-15 ncp11 (our next-gen Namecoin TLS interoperability software for Firefox, Tor Browser, and other NSS-based software) now builds without errors for Windows targets, including rbm descriptors. Getting it to build was a little bit more involved than just tweaking the rbm end of things, because the PKCS#11 spec requires that structs be packed on Windows, while Go doesn’t support packed structs. So, some minor hackery was needed (I wrote a C function that converts between packed and unpacked structs). Kudos to Miek Gieben (author of the Go pkcs11 package) for his useful sample code, which made this fix quite easy to code up.
2019-06-13 A few days ago I mentioned that ncp11 now builds in rbm. As you may recall, rbm is the build system used by Tor Browser; it facilitates reproducible builds, which improves the security of the build process against supply-chain attacks. I’ve now added several new projects/targets to Namecoin’s rbm descriptors:
2019-06-12 ncp11 is the next-gen Namecoin TLS interoperability project that Aerth and I have been cooking up in the Namecoin R&D lab for a while. (See my 35C3 slides and workshop notes for more info on it if you haven’t heard about it yet.) Last month, I mentioned that I intended to get ncp11 building in rbm. I now have ncp11 building in rbm for GNU/Linux 64-bit and 32-bit x86 targets. 32-bit support involved fixing a bug in ncdns’s usage of PKCS#11 (specifically, ncp11 was making type assumptions that are only valid on 64-bit targets, which produced a build error on 32-bit targets). I’ve tested the resulting 64-bit binary in a Debian Buster VM, and it works fine when used as a drop-in replacement for NSS’s CKBI library. (It looks like there are issues when loaded alongside CKBI, which I’ll need to debug when I have some free time, but this isn’t a release blocker, and the same issues are reproducible with the non-rbm binary I used at 35C3.)
Official anouncements will also be made on this BitcoinTalk thread.
Help keep us strong. You can donate to the Namecoin project here.