BitNames on Ecash: One Name, Everywhere, Owned by You (and Not by ICANN)

July 18, 2026 · 12 min read

This is the third piece in our series covering the seven BIP-300 sidechains launching alongside the eCash hard fork on August 21, 2026. Previous entries covered Thunder, the high-throughput payments chain, and zSide, the Zcash-grade privacy chain. Here we look at BitNames, the decentralized identity and naming sidechain.

Of the seven sidechains shipping at fork, BitNames is listed as live, with code developed under the repository plain-bitnames. It is the least flashy of the seven to describe in a sentence and arguably the most far-reaching in its ambitions. It is a chain for registering human-readable names that map to cryptographic keys, IP addresses, and arbitrary data. Put plainly, it is an attempt to build what Namecoin tried and failed to build fifteen years ago, and to succeed this time by fixing the specific economic and structural mistakes that killed the original.

What a Name Actually Buys You

When you type a website address into a browser today, the lookup travels through ICANN, the registrar system, and the DNS root servers. Each of those is a point of control. Governments seize domains. Registrars revoke names under political and legal pressure. Renewal depends on continued payment to a centralized intermediary that can be compelled to cut you off. The entire naming layer of the internet, the part that turns numbers humans cannot remember into words they can, sits on a hierarchy of trusted third parties.

BitNames replaces that hierarchy with cryptographic ownership. On the chain, the namealice belongs to whoever controls the corresponding private key, and it stays theirs without any central authority able to revoke it. As the technical design in the plain-bitnames repository describes, a name carries a 32-byte on-chain commitment. The associated data lives off-chain as a canonical JSON object, hashed with BLAKE3 and checked against that commitment, so that anything from an IP address to a public key to a service endpoint can be bound to the name and verified by anyone.

The implications run well past website addresses. A name can resolve to a public key for encrypted messaging, a payment address, a social handle, or a set of service records. That is what turns a naming chain into an identity chain.

The Point Is Identity Consistency

Paul Sztorc's fullest writeup of this idea lives on his Truthcoin blog post on BitNames, and its framing is worth taking seriously because it explains why a name service is more interesting than domain speculation.

His lead example is the "one login" problem. Today your username on one platform has nothing to do with your username on another. Each service maintains its own account silo, its own password, and its own authority to deplatform you. Sztorc describes a world where a service like Instagram would let you type in a username, look that name up in BitNames, find the public key stored there, and ask you to sign a message with the matching key. In his words, "I could therefore lay permanent claim to the psztorc account, at all services that support BitNames. I would own psztorc everywhere, even on new social media platforms that haven't been invented yet."

That is the core of identity consistency. Instead of renting your identity from each platform, you own a name at the protocol level and platforms point to it. The account becomes something you control and merely allow services to reference, rather than something a company issues to you and can take away.

This connects directly to a theme that has run through recent eCash Spaces. On the July 8 call, the discussion of BIP47 and the dream of texting money to a person as easily as texting words was, at bottom, the same problem BitNames solves: how do two people reliably learn each other's keys without a trusted intermediary and without copy-pasting error-prone addresses. Vlad Costea also pointed out that Samourai Wallet used PayNyms to give every user a memorable robot avatar and a vanity identifier, an early gesture at exactly the human-readable identity layer BitNames aims to make general.

Reputation, Trust, Communication, and Community

Once a name is a stable, self-owned anchor for a public key, several things that are hard on today's internet become straightforward.

• Reputation becomes portable. A name that has existed for years, accrued history, and been used consistently carries weight that a throwaway account cannot. Because the name is owned cryptographically rather than issued by a platform, the reputation attached to it survives the death of any particular service.
• Trust becomes verifiable. If a name resolves to a public key, then any message signed by that key is provably from the name's owner. Sztorc's Truthcoin writeup describes how this enables encrypted communication of all kinds between parties who have established each other's keys, and how it defends against the phishing and key-rotation failures that plague systems like the old onion-service naming.
• Communication gets a spam-resistant foundation. The BitNames design discusses "bit-introductions," a mechanism for handling the fundamental problem of unsolicited contact. The comparison Sztorc draws is to email, where the root problem is spam and the practical result is that you need Gmail or Yahoo to filter it for you. A naming and introduction layer lets you decide who can reach you without outsourcing that decision to a mail provider.
• Community building gets a fallback. One of the strategies described in the BitNames material is blockchain social media as a fallback, where the name is the durable identity and individual platforms are interchangeable front ends pointing at it. Deplatforming loses much of its force when the audience relationship is anchored to a name you own rather than to a follower count locked inside one company's database.

The design also includes thoughtful edge-case handling that most naming systems ignore. The Truthcoin writeup describes a SuperKey arrangement with secret veto keys that exist only to override a decision made under duress, and a rule that the SuperKey's power expires if unused for a year, so that "by just doing nothing for a year, the SuperKey owner can be freed from his toxic ability to re-assign domain names." These are the kinds of details that separate a system designed for real adversarial conditions from one designed for a demo.

Why Namecoin Failed

BitNames is not the first attempt at this. It is not even the second. The idea traces to BitDNS, discussed in the #bitcoin-dev IRC channel and on the Bitcoin forum in 2010, a conversation in which Satoshi Nakamoto himself participated, suggesting that a decentralized DNS could be built as a separate chain rather than bolted onto Bitcoin. That discussion produced Namecoin, launched in April 2011 by the pseudonymous Vincent Durham, the first fork of the Bitcoin codebase and the first project to implement merged mining. Its flagship product was the .bit top-level domain.

By most measures, Namecoin did not work. The reasons are instructive because BitNames is explicitly designed against them.

Trivial squatting economics. As one Bitcoin Stack Exchange analysis put it, at Namecoin's generation rate you could register thousands of domains every ten minutes, which meant registering names was so cheap that anyone could squat them all. Names were nearly free, so they had nearly no signal, and the namespace filled with speculative junk.

Almost no real usage. Research recounted in a Princeton empirical study of Namecoin and echoed in community postmortems found that of hundreds of thousands of registered names, only a tiny handful pointed at real content. One frequently cited figure is that roughly 30 genuine .bit websites ever existed, most of them mirrors of sites that already had conventional domains.

No resolver support. Because .bit was never part of the standard DNS, resolving it required running a Namecoin full node or special software. The OpenNIC alternative root that once resolved .bit dropped it in 2019. A naming system that ordinary browsers cannot resolve is a naming system almost no one will use.

Naming as a side feature. Namecoin ran name registration as one function of a general-purpose coin. The economics of the coin and the economics of the namespace were entangled and neither was optimized. Renewal mechanics were weak, and the project underestimated ordinary user inertia. As the Namecoin community itself has acknowledged over the years, the technology worked while adoption did not.

The blunt summary from a widely shared community discussion was simply that "Namecoin failed," not because the cryptography was broken but because the incentives around registration, renewal, and resolution were wrong, and because nothing compelled the wider internet to support it.

How BitNames Is Different

BitNames inherits the goal and discards the structure that sank the original. Several differences matter.

• It is purpose-built, not a side feature. BitNames is a dedicated sidechain for names and identity rather than a naming feature stapled to a general-purpose coin. The renewal mechanics and anti-squatting economics are designed in from the start rather than inherited by accident, a point emphasized in the project's own materials and consistent with Sztorc's long critique of Namecoin's design.

• It has no native token. As a BIP-300 drivechain, BitNames uses Bitcoin-pegged value for its transaction fees rather than minting a separate NMC-style coin. This removes one of Namecoin's core problems, the need to bootstrap and defend an independent currency whose price collapse after merged mining undermined the whole enterprise. Security comes from blind merge mining by the same miners securing the main chain, not from a thin pool of dedicated hashrate.

• It uses modern, verifiable data commitments. The plain-bitnames design keeps a compact 32-byte commitment on-chain and the full canonical JSON record off-chain, hashed with BLAKE3. That keeps the chain lean while letting names carry rich, verifiable data, which is a cleaner separation than Namecoin's practice of stuffing values directly into the chain.

• It is designed for the identity use case, not just DNS. Namecoin was framed primarily as censorship-resistant DNS. BitNames treats DNS as one application of a broader identity primitive that also covers logins, messaging keys, payment endpoints, and social identity, with adversarial features like the duress-resistant SuperKey built in.

• It respects existing name ownership. The Truthcoin writeup is explicit that the core design challenge is to respect two sets of property rights at once, existing domain owners and future BitNames users, and that names people already hold "belong to their old owners and cannot be grabbed." That is a deliberate contrast to the free-for-all land grab that defined early Namecoin.

None of this guarantees adoption. It is worth stating clearly that BitNames faces the same fundamental obstacle Namecoin never overcame, which is inertia. A naming system is only as useful as the number of services willing to resolve and honor it, and BitNames will launch, like the other sidechains, as new software that has to earn integration one platform at a time.

The eCash project's own readiness notes reflect this reality, with BitNames binaries rebuilt across macOS, Windows, and Linux through mid-2026 and the chain in active development ahead of launch. Live code is a starting line, not a finish.

Does BitNames Already Contain the DNS Database?

A natural first assumption, and one the reader made, is that BitNames arrives pre-loaded with the current DNS database, so that searching for google.com or google.bit in the client should return an existing entry. It does not, and the reason is central to how the system is designed.

BitNames does not ingest ICANN's records. Every name starts unclaimed and must be actively registered on-chain by someone. What the system does provide, described in Part 5 of Sztorc's BitNames essay, is a grandfathering guarantee for what he calls "ICANN-style BitNames" (ISBs), meaning names that end in a string which was a real top-level domain on the date BitNames launched, such as .com, .org, or .gov.

For those names, a "SuperKey" federation lets the legitimate ICANN owner always reclaim the matching BitName by proving control of the real domain, specifically by placing a bitname.txt file containing their public address in the site's root directory. As the essay puts it, "if you buy 'www.google.com' from ICANN, you will always be able to get 'www.google.com' from BitNames. No matter when you buy it."

Two consequences follow directly for the reader's experiment:

• An empty result for google.com simply means nobody has registered it yet on the network state being queried. The name is reserved in principle for Google via the SuperKey mechanism, but it does not exist as an entry until it is actually claimed.

• google.bit is a different case entirely. .bit was Namecoin's TLD and is not an ICANN top-level domain, so under the essay's definition it is a non-ICANN-style BitName, claimable by anyone on a first-come basis with no SuperKey protection.

So the mental model is not "a mirror of DNS" but "an empty namespace with a permanent escape hatch that lets real-world domain owners recover their exact names whenever they choose to."

Public Key, or IP Address Plus 32-Byte Commitment?

Sztorc's essay illustrates BitNames with a simple public-key example, while the plain-bitnames repository documents an IP-address-plus-commitment scheme. Both are real, and they are two layers of the same design rather than competing options.

The public-key use case is the conceptual headline. In the essay, Sztorc gives the login example: "Instagram, for example, would let me type in 'psztorc' as my username. It would then look up 'psztorc' in the BitNames system, and look up the public key there. Then Instagram would ask me to sign a message with that keypair." A name maps to a key, and control of the key proves control of the identity.

The repository describes the more general machinery that makes this and much more possible. Rather than storing all associated data on-chain, BitNames keeps a compact 32-byte commitment on-chain, optionally paired with IP/port addresses. Those addresses can host a JSON-RPC server exposing a bitname_commit method that returns a canonical JSON object (per RFC-8785). That object is hashed with BLAKE3, and the digest is compared against the on-chain 32-byte commitment; if they match, "any data contained in the JSON object can be considered to be associated to the BitName." The repo also notes the scheme is "optionally recursive," so a JSON object can commit to further commitments and additional servers.

In other words, the public key is simply one field that can live inside the committed data, alongside payment addresses, service endpoints, or social handles. The 32-byte commitment is the general primitive that keeps the chain lean while letting a name carry arbitrarily rich, verifiable off-chain data.

Why BitNames Is a Big Deal

The significance of BitNames is that it targets the piece of the decentralized internet that the cryptocurrency world has mostly failed to deliver. Money got decentralized. Identity and naming did not. Every decentralized application still typically resolves through centralized DNS and still leans on platform-issued accounts, which means every one of them retains a censorship chokepoint that the currency layer cannot remove.

Paul Sztorc's argument, made repeatedly across his writing and the recent Spaces, is that a genuinely censorship-resistant internet requires a censorship-resistant naming layer, and that without it the promise of the last thirty years of cypherpunk work stays incomplete. BitNames is the attempt to close that gap while pegged to Bitcoin and secured by Bitcoin's miners, rather than as yet another standalone altcoin asking users to buy its coin and trust its independent security.

There is a fitting historical symmetry here. The idea began in a 2010 conversation that included Satoshi Nakamoto, spun off into the first Bitcoin fork, and then largely stalled for fifteen years. BitNames is a bet that the concept was right all along and only the incentives were wrong. If it works, the payoff is not a better.bit domain. It is a name you own everywhere, a reputation that no platform can confiscate, and an identity layer for the internet that does not run through ICANN. Whether the market rewards that, as Sztorc is fond of saying, will be decided on the merits.