Namecoin Integration in Whonix

Hi Whonix devs,

Namecoin dev here. Some of you are probably already familiar with Namecoin. For those of you who aren’t, it’s basically DNS on a blockchain. We were the first project to fork the Bitcoin codebase (back in 2011). We’ve been a part of the C3 Monero Assembly since 34C3.

As you might have heard, the Namecoin and Tor Browser developers are running an experiment with Namecoin integration in Tor Browser. For details on the Tor Browser work, I’d highly recommend taking a look at my 36C3 talk on the subject; a video, slides, and workshop notes are available at 36C3 Summary (along with a very short lightning talk introducing Namecoin). As a quick example, you can download a current official Tor Browser Nightly binary for GNU/Linux [1], run it with the environment variable TOR_ENABLE_NAMECOIN=1, and visit http://submit.wikileaks.bit/ , which will take you to the WikiLeaks submission system onion service [2].

I’m reaching out to inquire if there’s interest in adding Namecoin to Whonix. Here are some of the potential benefits this could provide:

  1. Human-meaningful names for onion services, without relying on centralized lookup mechanisms like HTTPS Everywhere. (This is currently the initial focus of the experiment we’re running with the Tor Browser developers.)
  2. Domain names for non-onion websites that are resistant to censorship e.g. domain name seizures. A single Namecoin domain name can point to both an onion service and an IP address; Tor users will get the onion service (or the IP if no onion service exists); clearnet users will get the IP address; both are resistant to takedowns.
  3. TLS certificate validation that doesn’t rely on the public CA system. This is relevant for non-onion traffic over Tor, since Tor exit relays are in a good position to do MITM attacks if they can produce a fraudulent certificate. It’s also relevant for onion services with Whonix, since TLS makes onion services more meaningfully end-to-end in a Whonix-style threat model.

There are probably lots of interesting technical aspects to what a potential Namecoin integration in Whonix would look like. I’d definitely be up for discussing those if there’s interest in the general concept. I’m also happy to discuss more high-level questions if you have any. At Patrick’s request, I’ve created a separate thread for technical discussion about how this could be implemented (with this thread reserved for high-level / conceptual discussion), so that “should we implement it” discussion (in this thread) and “how could it be implemented” discussion (in the other thread) don’t distract from each other.

Would this be something that you might be interested in collaborating on?

PS: I also was able to obtain the Namecoin domain name whonix.bit. I’m happy to donate it to the Whonix developers if you’d like to point it to the Whonix website.

[1] It doesn’t work on Whonix yet; hence part of the motivation for this post.
[2] This is solely for demo purposes at this time; do not submit documents to WikiLeaks using this.

EDIT: Added link to technical discussion thread.


Because there are so many crypto related scams are vaporware… Before this comes up…

namecoin, as far as I know:

  • Not a scam coin.
  • Had never an ICO.
  • Jeremy would have had the skills to pull off an ICO during the 2018 crypto bubble but didn’t.

Some very basic questions…

What is the crypto currency (?) NMC (namecoin) being needed for?

Do users need NMC to resolve .bit domains?

Why does namecoin demand NMC or domain registration? Why doesn’t it accept Bitcoin and/or other crypto currencies?

1 Like

It’s a rate-limiting / anti-spam mechanism for name registrations. If there weren’t a cost to register names, then one spammer could, for example, pipe the entire trademark database of every country into a Bash script and grab all those names for themself without any cost.

When Namecoin was originally being designed in 2010 (under the name BitDNS), the original design (by Appamatto) didn’t involve a currency; instead, users would use PoW directly to mine blocks that contained name registrations. However, it was pointed out (by Theymos) that this would be both a UX and security issue: a UX issue because users would need to be a miner to register a name (and would need to wait until they mined a block before they’d get their name), and a security issue because the UX issue would result in miners offering to register names on behalf of non-miner users, becoming a trusted 3rd party that could frontrun the names instead. So the solution was to have a “domain credits” pseudo-currency that miners would generate, which could be transferred around (similar to bitcoins) so that non-miners could register names in a trustless manner.

No; resolving names is gratis; it does not require spending or possessing any coins or creating any kind of blockchain transaction.

The concept of using cryptocurrency created on one blockchain to issue transactions on another blockchain is called a pegged sidechain. It is a cool concept, and I would like to see it implemented in theory. But, no one has figured out how to make it work in practice. The closest thing that’s been deployed in the real world is Blockstream Liquid, which uses a federated peg, i.e. there is a centralized set of validators who sign the transfers between chains. Namecoin values decentralization, so we don’t think that approach is acceptable for our use cases.

There are also scalability concerns with using bitcoins to register Namecoin names, specifically that this would require full Namecoin nodes to also be full Bitcoin nodes. Appamatto’s original BitDNS design involved putting both Bitcoin and Namecoin into a single blockchain (which he called BitX); Bitcoin founder Satoshi Nakamoto was very much against that, and argued that users of one system shouldn’t need to download the blockchain of the other system: “Piling every PoW quorum system into one dataset doesn’t scale.” Satoshi instead recommended that they use separate blockchains that share miners, and he proposed the system of merge-mined sidechains to achieve this, which Namecoin implemented. As a result of Namecoin being a merge-mined sidechain of Bitcoin, Bitcoin miners can mine Namecoin as well at approximately no additional cost; for this reason, Namecoin has a very high hashrate (the majority of Bitcoin hashrate also mines Namecoin, and there have even been a few rare instances where Namecoin’s hashrate exceeded that of Bitcoin).

That said, it is possible to exchange bitcoins for namecoins in a decentralized way. The simplest way to do this is via a decentralized Bitcoin exchange (Bisq supports exchanging bitcoins for namecoins), but a more interesting approach is cross-chain atomic trades, which utilize some interesting features of Bitcoin/Namecoin transactions to allow trading bitcoins for namecoins atomically, i.e. there is no counterparty risk since either both sides of the trade go through, or neither does. Right now, I’m not aware of any atomic cross-chain trade systems that support Tor, but we are very much open to the concept of implementing such support in the future.

One other benefit of Namecoin not using bitcoins to register names is anonymity. Bitcoin is vulnerable to graph analysis to deanonymize transactions, so if Namecoin names were registered via bitcoins, that would lead to deanonymization of Namecoin name owners. In contrast, since namecoins can be purchased on an exchange for arbitrary currencies, users who care about anonymously registering names can buy namecoins on an exchange using an anonymity-friendly cryptocurrency like Monero, which means that if someone tries to trace the owner of a Namecoin wallet via graph analysis, all they’ll figure out is that it was purchased via Monero, at which point the trail goes cold (assuming that Monero’s anonymity works as intended). I gave a talk at 34C3 that goes into more detail about anonymity in Namecoin; video is here, and slides are here.

Hopefully that answers those questions.

1 Like

For what it’s worth, I (rehrar from Monero) like to say that I know Jeremy personally, and he’s a stand up guy with incredible technical skills.

Also, Namecoin is one of the few non-scammy cryptocurrencies in existence. Having worked in the space for 4 years now, I’m at an all-time high cynicism for anything cryptocurrency related (similar to anyone working in tech trusting tech less and less as the amount of time in the space increases). Namecoin is one of the few projects that continues to hold my respect.

They’re truly trying to change the internet for the better.

1 Like
  • How does DDOS effect Namecoin/.bit website? What will happen if an attack launched on hidden service .onion/.i2p do namecoin get effected as well? (assuming this .onion mirrored (not sure the right term here) to use namecoin DNS)

  • And will the onion service going to be still operating while using onion balance? If no, what are the alternatives?

  • And how much namecoin does resist country level firewall protocol blockage?

good place to mention these stuff as well.

1 Like

If the IP address and/or onion service that a Namecoin domain points to is down (e.g. due to DDoS), then Namecoin won’t magically bring it back up. However, if a website’s DNS infrastructure is under a DDoS, then maybe the website could stay available via Namecoin. On the flip side, if the Namecoin network were successfully DDoSed, then that could take down Namecoin websites even if the website’s IP or onion is still online. Historically, there have been quite a few attempts to DDoS various parts of the Bitcoin network (e.g. DDoSing the P2P nodes, DDoSing the miners, DDoSing the ElectrumX servers), and none of these attacks were particularly successful. DDoSing Namecoin is conceptually similar to DDoSing Bitcoin, since the code is basically the same (with the difference that the Namecoin network is smaller, so there are probably fewer targets you’d need to DDoS in order to bring Namecoin down).

I’ve never used Onionbalance myself, nor tested it with Namecoin, but I would expect that if you put an Onionbalance frontend .onion domain into Namecoin, it should work fine. There’s nothing in Namecoin that would be likely to interfere with or replace the Tor logic that handles Onionbalance.

You could also include multiple .onion domains in Namecoin, without using Onionbalance, and Namecoin will randomly pick one. (I didn’t test this extensively, but the code is there and it should work.) This is fine for load balancing but it won’t work for failover. (And of course putting multiple .onion domains in Namecoin will mean more blockchain bloat and higher renewal fees, so it’s not really recommended unless there’s a strong reason to do so. Onionbalance is probably a better approach for most users.)

Probably about as much as Bitcoin does, since the protocols are virtually identical. I’m not personally aware of any governments that tried to blacklist Bitcoin protocols (maybe there are cases I’m not aware of; I’ve never actively looked for such cases), but I am aware that the OONI test list includes various Bitcoin-related things, e.g. the Bitcoin Core website, some exchange websites, and the domain names of some Bitcoin DNS seeds. So presumably that means OONI thinks that some governments might attempt to blacklist Bitcoin via such mechanisms. (I’m pretty sure Namecoin’s website is blacklisted in Belarus for the last few months, but I don’t think they’re censoring the protocol, just the website.) Namecoin Core and Electrum-NMC both support routing all traffic via Tor (with stream isolation), so in practice I’d expect Tor’s censorship resistance to protect Namecoin traffic pretty well; I’m definitely not aware of any DPI systems that can censor Bitcoin traffic while it’s tunneled inside Tor, and I’m guessing I would have heard about such things if they were in use.

Yep, good point. I will look into adding the Q&A from this thread into our FAQ.


Does namecoin support deterministic/reproducible build?

Does it support and ship its own apparmor profile? (or any MAC/sandboxing method)

1 Like

Namecoin Core is reproducible using Bitcoin Core’s Gitian-based build system. We routinely audit for reproducibility before releasing binaries.

Electrum-NMC is reproducible for GNU/Linux and Windows platforms using Electrum’s Docker-based build system. It’s not reproducible for macOS and Android/Linux platforms (upstream Electrum issue), and we don’t routinely audit for reproducibility yet. Tor Browser has its own RBM-based build system for Electrum-NMC, which also should be reproducible, but I don’t think the Tor devs routinely audit that for reproducibility.

Most of our other projects (e.g. ncdns and ncprop279) are reproducible via Tor Browser’s RBM-based build system, but we don’t routinely audit for reproducibility yet. Last I looked, there’s a linker bug that causes ncp11 to not be reproducible even when built in RBM.

We are leaders in the field of reproducible builds. For example, the Debian guest support in Gitian (which was used by Tor Browser reproducible builds for a while) was implemented by one of our developers (Joseph Bisch). We are also working on improvements to Tor Browser’s reproducible build workflow that will allow using CI services such as Cirrus as co-signers for additional builder diversity (I gave a presentation on this at Tor Demo Day recently).

It should be noted, of course, that if Whonix chooses to use Debian-packaged Namecoin software, the reproducibility will be a function of Debian’s build process, not the build process we use to release our own binaries.

Not yet. For Namecoin Core and Electrum-NMC, I’d expect any existing profiles for Bitcoin Core and Electrum to be easily portable to Namecoin. (If this is deemed to be relevant to whether Whonix adds Namecoin, let me know and I can look into bumping the priority of this.)


Preferable to have apparmor profile even for the future sake of namecoin, Leaving the app hanging without any mac or sandboxing is not preferable approach anymore.