Pseudonymous Was Never Anonymous: What Bitcoin's Transaction Graph Taught the Unlinkability Engineers

1. Men With No Names#

In 2013 a team of academics set out to test a claim everyone repeated and almost no one had checked: that Bitcoin was anonymous. They broke no signatures and stole no keys. They spent a few dollars at real exchanges and gambling sites, ran two simple heuristics over the public ledger, and watched thousands of "anonymous" addresses collapse into named clusters. Their paper's subtitle said the quiet part out loud -- they were characterizing payments among men with no names ^[1] -- and the names, it turned out, were never the point.

Here is the fact that dissolves the confusion. Bitcoin is not private cash. It is the most transparent financial record ever built: every payment ever made is public, permanent, and replicated to tens of thousands of machines worldwide, open to anyone with a laptop and patience.

Dorit Ron and Adi Shamir walked the entire graph that same year and treated it as one giant object of study ^[2]; Fergal Reid and Martin Harrigan had shown two years earlier that the public graph alone links addresses ^[3]. The users in these studies attached no names to their keys, used fresh addresses, and lost their privacy anyway -- because the ledger let their actions be linked.

That is the distinction this article makes precise, worth stating as a claim you can hold before we prove it:

Anonymity is the absence of linkability, not the absence of names -- and Bitcoin is the largest live proof of the gap.

The rest of this piece is one argument, marshaled from two very different worlds. From Bitcoin we get the negative proof: a system that mints unlimited name-free pseudonyms and still cannot make its users anonymous, because a public ledger cannot stop those pseudonyms from being linked. From the identity and credential cryptographers -- who build anonymous credentials, anonymous attestation, and blinded tokens -- we get the constructive proof: engineers who stopped chasing "no name" and built "no linkage" as a first-class property, and discovered exactly what it costs.

To adjudicate between the two we need a vocabulary precise enough to tell pseudonymity, anonymity, and unlinkability apart. And to see why fresh pseudonyms were never enough, we have to go back before Bitcoin existed -- to a cryptographer who, in 1981, had already defined the real problem.

2. Two Lineages That Collide#

The story does not begin with Bitcoin. It begins with metadata. By 1981, public-key cryptography could already hide what you wrote, but it could not hide whom you wrote to. The pattern of who talks to whom, who pays whom, who shows up where, is identifying all by itself, even when every message is sealed. Two engineering cultures noticed this at different times and drew opposite conclusions about how to fix it. Their collision, decades later, is this article's subject.

The first culture is the identity lineage, and its founder is David Chaum. In 1981 he described mix networks and digital pseudonyms: a way to relay messages so that no observer, not even the relays, could link a sender to a receiver ^[4]. The next year, at CRYPTO '82, he introduced the primitive that would echo through the next forty years -- the blind signature, published in the 1983 proceedings ^[5]. A blind signature lets a bank sign a token it cannot see; when the token reappears in payment, the bank recognizes its own signature but cannot connect it to the withdrawal. The link between "who withdrew" and "who spent" is severed by construction.

Chaum then generalized the idea into a program with an unusually blunt name: Security without Identification ^[6], subtitled "Transaction Systems to Make Big Brother Obsolete." The goal, stated plainly in 1985, was to authorize an action without identifying the actor. That is unlinkability, engineered as a first-class property -- a full generation before the ledger that would become its most famous counterexample.

The second culture is the ledger lineage, and its founding document took the opposite fork. In 2008, Satoshi Nakamoto's Bitcoin whitepaper proposed a privacy model explicitly weaker than Chaum's. "Satoshi Nakamoto" is itself a pseudonym whose holder remains unknown -- the author of the pseudonymity model is, fittingly, its own best example. Bitcoin has no trusted mix and no bank to break a link, so Section 10 fell back to a simpler idea: keep public keys anonymous, and use "a new key pair for each transaction" so payments cannot be trivially tied to a common owner ^[7]. Unlimited free pseudonyms, no names attached.

But the same section that promised privacy-through-freshness immediately conceded its own limit. Nakamoto wrote that "some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner" ^[7]. The leak was not discovered by attackers years later. It was disclosed by the designer, in the founding text, in the very paragraph that promised privacy.

timeline
title Two lineages of privacy engineering
section Identity lineage engineers unlinkability
1981 : Chaum mix networks and digital pseudonyms
1982 : Chaum blind signatures for untraceable payments
1985 : Chaum Security without Identification
2001 : Camenisch and Lysyanskaya anonymous credentials
2004 : BBS short group signatures and Direct Anonymous Attestation
2026 : BBS draft with unlinkability as a named property
section Ledger lineage hides names
2008 : Nakamoto Bitcoin fresh pseudonyms and the Section 10 leak
2011 : Reid and Harrigan link the public graph
2013 : Ron and Shamir and Meiklejohn deanonymize at scale
2023 : Silent Payments BIP 352 revives fresh addresses correctly

Both camps used the same word -- anonymous -- and meant different things by it. Chaum meant unlinkability: an adversary cannot relate two of your actions. Nakamoto meant namelessness: your key carries no legal identity. For most of a decade the difference stayed blurred, because no one had run the experiment. Then someone did, and the blur became a chasm. To describe it precisely -- to say exactly what Bitcoin delivered and what it failed to deliver -- we need a vocabulary sharper than the marketing word "anonymous." That vocabulary already exists, and it was written down the year before the deanonymization papers appeared.

3. The Taxonomy, Made Rigorous#

"Anonymity is having no name" feels obviously correct. It is wrong, and correcting it is the whole game.

The correction comes from the canonical reference for this vocabulary: Andreas Pfitzmann and Marit Hansen's terminology document, refined over a decade of drafts into a version the field treats as authoritative ^[8]. Its definitions are careful, and the care is the point. Start with the one that does the heavy lifting.

With unlinkability in hand, anonymity is not a primitive notion at all. It is a consequence.

Read that last definition twice, because it is the thesis of this entire article stated in the field's own words. Anonymity is unlinkability -- specifically, the unlinkability of a subject to an action, within a set. Namelessness does not appear anywhere in the definition. A name is just one especially convenient linking handle; remove it and every other handle -- co-spending, timing, amounts, reused identifiers -- still links you exactly as well.

That leaves the third term, the one Bitcoin actually delivers.

Here is the nuance the rest of the article turns on. A Bitcoin address is nominally a transaction pseudonym -- the whitepaper's advice was to generate a fresh one per payment. But a transaction pseudonym only stays "transaction" if it is used once and never linked to its siblings. The moment two addresses are spent together, or a change output chains them, they fuse into a single persistent pseudonym -- a stable identifier tracking one entity across time. Reuse and linkage silently promote the weakest, most private kind of pseudonym into the strongest, most trackable kind.

The table makes the hierarchy visible. Pseudonymity is a property of a single identifier. Unlinkability is a property of a pair of actions relative to an adversary. Anonymity is unlinkability plus a crowd. They are not three grades of the same thing; they are three different things, and a system can satisfy the first while failing the other two completely.

flowchart TD
A["Anonymity set: the crowd of possible subjects"] --> B["Anonymity: a subject is not identifiable within the set"]
C["Unlinkability: an attacker cannot relate two items of interest"] --> B
D["Pseudonymity: a name-free identifier, persistent to one-time"] --> E{"Is the pseudonym linkable?"}
E -->|"reused or co-spent"| F["Collapses to a persistent, attributable identity"]
E -->|"unlinkable across actions"| G["Approaches anonymity within the set"]

One more consequence falls out of these definitions before we move on, and it decides everything that follows: because linkability is defined relative to an attacker, "is this system anonymous?" is not a well-formed question. The only well-formed version is unlinkable against whom, across which actions, within which anonymity set? Hold that question; it becomes the practitioner's checklist at the end.

Namelessness is not the property. Unlinkability is. Anonymity is the unlinkability of a subject to its actions within an anonymity set -- so a system can hand out unlimited name-free pseudonyms and still fail to make anyone anonymous, as long as it cannot stop those pseudonyms from being linked.

If that is right, then somewhere there should be a system that mints infinite fresh pseudonyms and still deanonymizes its users wholesale. There is, and it is the most-scrutinized ledger on Earth.

4. How Linkage Beat Pseudonymity, Generation by Generation#

Nakamoto conceded the leak in Section 10. What followed was a decade of attackers turning that single concession into a science -- and not one of them ever broke a signature or recovered a key.

First, the minimum mechanics, because the heuristics are unintelligible without them.

Two facts about that model do all the damage. First, a transaction can have several inputs, and to spend them all it must present a valid signature for each -- which is only possible if one party controls all of them. Second, because a UTXO must be spent whole, a payment almost never matches your coin exactly, so the wallet sends the remainder back to itself as a change output. Both facts are structural. Neither can be turned off. And each becomes a linking channel.

Watch the attack lineage escalate. It starts from Nakamoto's baseline: fresh, name-free pseudonyms, one per payment. In 2011 Reid and Harrigan applied common-input-ownership to the public graph and showed that fresh addresses collapse into connected components -- distinct addresses, provably one owner, from nothing but arithmetic on the ledger ^[3]. In 2013 Sarah Meiklejohn's team added the second structural leak, change detection, then did something operationally devastating: they transacted with real exchanges, gambling sites, and mining pools to plant known addresses, and let the clustering propagate those labels until anonymous clusters wore real names ^[1].

The same year, Ron and Shamir analyzed the entire graph quantitatively, tracing flows of large balances across the whole system ^[2], and Androulaki and colleagues independently confirmed that ordinary user behavior defeats the pseudonymity in practice ^[10] -- a result echoed by structural analyses of the whole transaction graph ^[11]. What today's commercial chain-analysis firms sell is, at its core, this public academic template operationalized at industrial scale ^[1].

"Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner." -- Bitcoin whitepaper, Section 10 ^[7]

The clustering itself is almost insultingly cheap. Each "these belong together" fact is an edge; grouping addresses into entities is a union-find (disjoint-set) pass that runs in near-linear time. Union-find over $m$ union operations on $n$ elements costs $O(m \cdot \alpha(n))$, where $\alpha$ is the inverse Ackermann function -- effectively a constant. The deanonymization is not just possible, it is trivial to compute ^[12]. You can watch it happen on a handful of addresses. The code below feeds four transactions' worth of co-spent inputs into a union-find and recovers the entities. No names are supplied and no keys are broken; the structure alone betrays the owners.

// Common-Input-Ownership Heuristic as a union-find over the public graph.
// No names and no broken keys: co-spent inputs collapse fresh addresses into one entity.
const parent = {};
function find(x) {
if (parent[x] === undefined) parent[x] = x;
return parent[x] === x ? x : (parent[x] = find(parent[x]));
}
function union(a, b) { parent[find(a)] = find(b); }

// Each transaction lists the input addresses it co-spends (one owner signs all inputs).
const txInputs = [
['alice_a1', 'alice_a2'],  // tx1: two fresh addresses spent together
['alice_a2', 'alice_a3'],  // tx2: chains a third address in
['bob_b1',   'bob_b2'],    // tx3: an unrelated pair
['alice_a3', 'alice_a4'],  // tx4: extends the first cluster again
];
for (const inputs of txInputs)
for (let i = 1; i < inputs.length; i++) union(inputs[0], inputs[i]);

const clusters = {};
for (const a of Object.keys(parent)) {
const r = find(a);
if (clusters[r] === undefined) clusters[r] = [];
clusters[r].push(a);
}
const total = Object.keys(parent).length;
console.log('Recovered entities from ' + total + ' fresh, name-free addresses:');
let n = 0;
for (const root in clusters)
console.log('  entity ' + (++n) + ': ' + clusters[root].sort().join(', '));

Four transactions, six fresh addresses, and out fall two entities: Alice's four addresses fused into one, Bob's two into another. That is the entire trick behind "Bitcoin isn't anonymous," and it never touches a name.

flowchart LR
A["Fresh address A"] --> T1["Tx 1 co-spends A and B"]
B["Fresh address B"] --> T1
T1 --> C["CIOH unites A and B as one entity"]
T1 --> D["Change returned to fresh address D"]
D --> E["Change detection chains D into the entity"]
E --> F["Tx 2 spends D, extending the cluster"]
C --> G["One attributable cluster, no key broken"]
F --> G

The change output deserves its own definition, because "detect the change" is where naming leaks turn into cross-transaction tracking.

Naming change detection is not enough; a practitioner identifies it from converging signals, no one of which is decisive:

1. The fresh one-time address. Change goes to a never-before-seen address that is spent exactly once and never reused. That "appears once, gets spent, is not a self-transfer" shape is the engine of the peeling chain and the heart of Meiklejohn's change heuristic ^[1].
2. Input-matching script type. Change usually inherits the inputs' script type; an output of a different type is more likely the counterparty's payment. BIP 78 describes exactly this under "change identification from scriptPubKey type": if all inputs spend one script type, the change output likely shares it ^[13].
3. The round-number remainder. A round payment (say 0.1 BTC, possibly round only after fiat conversion) leaves a non-round remainder, and the non-round output is the change. BIP 78 lists this as "change identification from round change amount": a round output likely belongs to the receiver, so the other one is change ^[13].
4. The unnecessary-input / optimal-change tell. If treating the smaller output as the payment would have made one of the spent inputs unnecessary -- the wallet could have used fewer inputs and paid less fee -- then the larger output is the payment and the smaller is change ^[9].
5. Address-reuse tells. Any output reusing a previously seen address violates "one-time" and is unlikely to be fresh change, which by elimination points at the real change ^[9].

The heuristic is deliberately conservative, because one wrong change-link can merge two unrelated super-clusters and poison an entire analysis. That conservatism is precisely why the strongest defenses are built to attack change detection and common-input-ownership at the same time.

Now watch the defense lineage, which moves in lockstep with the attack -- each countermeasure targeting a specific linkage channel, never a name. The baseline is address rotation: HD wallets derive unlimited fresh addresses from one seed, so no single address accumulates a profile ^[14]. It fails immediately against CIOH and change, for the reasons above. The next idea was to hand your coins to a custodial mixer that pools and returns them -- but that just relocates the linkage to an operator who can log it, steal the funds, or be prosecuted.

That trustless successor is CoinJoin: many payers combine inputs into one collaborative transaction so that common-input-ownership becomes false -- the inputs no longer share an owner, and the core clustering assumption breaks ^[16]. ※ Gregory Maxwell sketched the idea in a 2013 forum thread bluntly titled "I taint rich!" before the canonical write-up ^[17]. Maxwell's 2013 proposal made this practical ^[18], and modern coordinators such as WabiSabi refined it ^[19]. But equal-output CoinJoins are detectable, and they leave "toxic change" behind.

So Nicolas Dorier's PayJoin (BIP 78, 2019) took a subtler route: build an ordinary-looking payment whose inputs belong to two parties and whose apparent change is not change at all -- poisoning common-input-ownership and change detection at once, invisibly ^[13]. And Silent Payments (BIP 352, 2023) finally revived Nakamoto's "fresh address per payment" ideal in a form that actually works, deriving unlinkable receive addresses non-interactively ^[20].

flowchart LR
subgraph Attacks["Linkage attacks escalate"]
A1["CIOH clustering"] --> A2["Change detection"]
A2 --> A3["Whole-graph flow"]
A3 --> A4["Entity tagging at scale"]
A4 --> A5["Receiving-address linkage"]
end
subgraph Defenses["Each defense answers one channel"]
B2["CoinJoin falsifies CIOH"]
B3["PayJoin poisons CIOH and change"]
B4["Silent Payments removes receive linkage"]
end
B2 -.targets.-> A1
B3 -.targets.-> A2
B4 -.targets.-> A5

Step back and the pattern is unmistakable. Not one attack breaks a signature or recovers a key; every one is a new way to link. And not one defense hides a name; every one severs a specific linkage channel. Both sides conceded the names were gone before the game even started. Which means every base-layer defense is a patch bolted onto a system that leaks by construction -- unlinkability here is always added, never native. Which raises the obvious question: what would it look like to build the missing property in from the start?

5. Engineering Unlinkability Directly#

While Bitcoin's base layer fought linkage after the fact, the other lineage had been building the absence of linkage as a first-class property since 1982. Its conceptual move is the one this whole article is arguing for: stop hiding names, and make actions uncorrelatable instead.

The starting point is Chaum's blind signature. A bank signs a token without seeing it; later the token is spent and verified, but the bank cannot link the spend to the withdrawal. That is a one-show unlinkable token -- authorization stripped of identification.

The goal was always to authorize an action without identifying the actor -- unlinkability, decades before the ledger that would prove its absence. -- after Chaum, "Security without Identification," 1985 ^[6]

A one-show token is powerful but limited: to stay unlinkable you must use each token once. The next question is the hard one. Can a single credential be shown to many verifiers, reveal a different subset of its attributes each time, and still leave those showings mutually uncorrelatable? Two definitions pin down what we are asking.

Camenisch and Lysyanskaya answered yes in 2001, and the mechanism is the key to everything. Instead of ever showing the issuer's signature, the holder proves in zero knowledge that they possess a valid signature over attributes satisfying the verifier's query ^[23]. A zero-knowledge proof convinces a verifier a statement is true while revealing nothing beyond its truth; because the proof is freshly randomized every time, two showings share no common bytes to correlate. This is the CL anonymous-credential lineage, later rebuilt on bilinear pairings for compactness ^[24], which is where the modern short signatures enter.

BBS is the primitive that makes this cheap enough to ship: an issuer signs a whole block of attributes with one short signature, and the holder derives a re-randomized zero-knowledge proof that discloses only the attributes it chooses. Direct Anonymous Attestation, standardized into the TPM in 2004, applied the same idea to hardware attesting to its own genuineness without a serial number ^[27]. The mechanism, in one picture:

sequenceDiagram
participant I as Issuer
participant H as Holder
participant V1 as Verifier 1
participant V2 as Verifier 2
I->>H: Sign a block of attributes once with one BBS signature
Note over H: The holder never reveals the signature itself
H->>V1: Derive a fresh zero-knowledge proof, disclose only country
H->>V2: Derive another fresh proof, disclose only licence class
Note over V1,V2: Colluding, they still cannot correlate the two proofs

Now the twist that makes this article one argument rather than two. What happens if a credential format skips the zero-knowledge step and simply hands the verifier the issuer's signature along with the disclosed fields? Then every presentation carries the same stable signature, and that signature is a persistent identifier -- exactly like a reused Bitcoin address. Selective disclosure hid the birth date, but it did nothing about the correlating handle riding along underneath. The demo makes the failure concrete: two presentations disclosing disjoint fields still share one issuer signature, and that alone links them.

// Two selective-disclosure presentations that carry ONE stable issuer signature
// are trivially linkable: the reused-address bug in credential form.
const credential = {
attributes: { name: 'Ada', dob: '1990-01-01', country: 'IE', licenceClass: 'B' },
issuerSignature: '0x8fA3c17e',   // signed once, then reused on every presentation
};
const present = (fields) => ({
disclosed: Object.fromEntries(fields.map(f => [f, credential.attributes[f]])),
sig: credential.issuerSignature,
});
const p1 = present(['country']);       // shown to a bar
const p2 = present(['licenceClass']);  // shown to a car-rental desk
console.log('Presentation 1 discloses:', JSON.stringify(p1.disclosed));
console.log('Presentation 2 discloses:', JSON.stringify(p2.disclosed));
const overlap = Object.keys(p1.disclosed).some(k => k in p2.disclosed);
console.log('Disclosed fields overlap?', overlap);
console.log('Same issuer signature?', p1.sig === p2.sig, '(links both shows to one subject)');

This is why the impossibility at the center of the identity domain must be stated carefully, because stated loosely it seems to contradict the escape hatches the field actually uses.

For a single, reusable credential shown repeatedly, selective disclosure with multi-show unlinkability requires zero knowledge. That is an impossibility result, not an engineering gap -- it is why BBS pays the zero-knowledge price and lands unlinkable, while a stable-signature baseline refuses the price and stays linkable. The escape hatches do not beat the theorem: batch issuance (a fresh single-use credential per show) and pairwise identifiers (a different identifier per verifier) change the architecture and buy a different unlinkability property that sits outside the theorem's scope ^{[28, 29]}.

None of this is a lab curiosity. BBS is an active IRTF CFRG draft (Informational status), and it is being carried into deployment-class evaluation: the W3C has a Data Integrity cryptosuite built on it for "selective disclosure and unlinkable derived proofs" ^[30], and the European Union's digital-identity architecture is actively evaluating BBS against a legal unlinkability mandate ^[28]. So the constructive proof exists, it is specified, and it is moving. The question for a practitioner in 2026 is what the whole toolkit looks like -- laid on the same table as Bitcoin's best base-layer answer.

6. The Unlinkability Toolkit (2026)#

Two arms races, one axis. Put the 2026 state of the art from both worlds on the same table and the same column decides every row: not "does it hide a name" but "which linkage does it sever, and against whom."

Start with the identity toolkit, where unlinkability is engineered in. BBS leads. Its IRTF CFRG specification gives unlinkability its own named heading (section 3.3.7, literally titled "Unlinkability"), stating that a verifier cannot correlate multiple proofs generated from the same signature or by the same prover ^[22]. That is a first-class, spec-level property, not a footnote. A reference implementation proves it is buildable ^[31], and it is being evaluated in standards and pilots: the W3C Data Integrity cryptosuite for BBS ^[30] and the EU digital-identity framework's zero-knowledge evaluation against a statutory unlinkability requirement ^[28].

The second tool is cheaper and already ubiquitous: blinded tokens built on oblivious pseudorandom functions.

An OPRF (and its verifiable variant, the VOPRF) lets a server issue a token it cannot later recognize, so redemption is unlinkable to issuance ^[32]. This is the engine of Privacy Pass, whose architecture spells out issuer-client unlinkability explicitly -- and, crucially, warns that stacking multiple attestations shrinks the anonymity set, a limit we will return to ^[33]. Where BBS buys rich multi-show unlinkable selective disclosure at a high price, OPRF tokens buy cheap one-or-limited-show anonymity for anti-abuse and rate-limiting.

Direct Anonymous Attestation is the third tool, and it must be presented honestly -- as a design example, not a deployment claim.

Against these sits the linkable baseline the major identity rollouts actually specify today: the ISO mobile-driving-licence format (mdoc) and SD-JWT verifiable credentials. Both make selective disclosure mandatory. Neither makes you unlinkable.

Now the Bitcoin counterpoint on a transparent ledger, where the same property can only be bolted on. Three defenses represent the 2026 base-layer state of the art. CoinJoin (matured in coordinators like WabiSabi) falsifies common-input-ownership by combining many payers into one transaction ^[19]. PayJoin quietly poisons both common-input-ownership and change detection inside an ordinary-looking payment ^[13]. And Silent Payments removes receiving-address linkage entirely, using an elliptic-curve Diffie-Hellman shared secret so the sender derives a unique output per payment ^[20].

Silent Payments is worth seeing in mechanism, because it is the base layer's closest approximation to engineered receiver-unlinkability. The receiver publishes one static scan key $B$. For each payment the sender derives a fresh output using an ECDH shared secret with their own input key: $P = B + \mathrm{hash}(a \cdot B) \cdot G$. Because $a \cdot B = b \cdot A$, the receiver recomputes the same secret by scanning the chain and recognizes payments addressed to them ^[20].

sequenceDiagram
participant S as Sender
participant L as Public ledger
participant R as Receiver
Note over R: Publishes one static scan key and spend key
S->>S: Derive an ECDH shared secret from own input key and receiver scan key
S->>L: Post a unique taproot output derived from that shared secret
R->>L: Scan each transaction and recompute the shared secret
Note over R: A match reveals a payment addressed to the receiver
Note over S,R: Two payments to the receiver land at distinct, unlinkable outputs

The equality of the two shared secrets is the whole trick. A toy prime-field stand-in shows sender and receiver landing on the same value (real deployments use secp256k1 ECDH per BIP 352, and this demo uses BigInt so the modular arithmetic never overflows JavaScript's safe-integer limit):

// Silent Payments derive a unique output per payment from an ECDH shared secret.
// Sender and receiver compute the SAME secret, so each payment lands at a distinct address.
// Toy prime-field stand-in for secp256k1; BigInt avoids the 2^53 safe-integer overflow.
function modpow(base, exp, mod) {
base %= mod;
let result = 1n;
while (exp > 0n) {
  if (exp & 1n) result = (result * base) % mod;
  base = (base * base) % mod;
  exp >>= 1n;
}
return result;
}
const p = 2147483647n;             // 2^31 - 1 (Mersenne prime)
const G = 5n;                      // public generator
const a = 1234567n, b = 7654321n;  // sender and receiver private scalars
const A = modpow(G, a, p);         // sender public key  A = a*G
const B = modpow(G, b, p);         // receiver public key B = b*G
const senderSecret   = modpow(B, a, p);  // a * B
const receiverSecret = modpow(A, b, p);  // b * A
console.log('Sender derives  a*B =', senderSecret.toString());
console.log('Receiver derives b*A =', receiverSecret.toString());
console.log('Shared secret matches?', senderSecret === receiverSecret);

Read the two tables together and the thesis stops being a slogan and becomes an observation. The identity table builds unlinkability in; the Bitcoin table bolts it on. But in both, the winning column is never "hides a name" -- every method concedes the names are already gone. The winning column is always the same: severs a linkage channel, against a named adversary, across a defined set of actions. That is what buying unlinkability actually costs, in both worlds.

7. Different Prices for the Same Property#

"Unlinkable" is not a single thing you buy. It is a property with a price tag, and the price changes with the threat model. The identity domain sells it four ways.

The first is BBS: multi-show, multi-attribute unlinkability, paid for with zero-knowledge proofs over pairing-friendly curves. This is the expensive, powerful option, and the exact case the impossibility governs -- one reusable credential, shown many times, staying uncorrelatable. The second is blinded tokens on an OPRF: cheap, but scoped to one-or-limited-show anonymity for anti-abuse, with no rich selective disclosure ^[32].

The third is pairwise identifiers: give each verifier a different identifier for the same subject, so two relying parties cannot correlate you by a shared handle. NIST's federation guidance requires exactly this -- a different identifier per relying party ^[29] -- and the EU wallet framework treats per-relying-party pseudonyms (for instance via WebAuthn) as a way to ensure unlinkability across verifiers ^[37]. The fourth is batch issuance: hand the holder many single-use credentials, so each presentation spends a fresh one and there is nothing stable to correlate ^[28].

The last two matter for a subtle reason, and getting it wrong makes the article contradict itself.

Pairwise identifiers and batch issuance reach multi-show unlinkability without zero knowledge, which looks like a counterexample to the section 5 impossibility. It is not. The theorem is about a single, reusable credential shown repeatedly. Batch issuance abolishes the "single, reusable" premise by minting a fresh credential per show; pairwise identifiers abolish the "shown to many verifiers" premise by giving each verifier its own identifier and relocating the linkage to the issuer, who still sees everything. They do not beat the theorem -- they step outside its scope by changing the architecture, and they pay a different price (storage, reissuance, or trust in the issuer) to do it ^{[28, 29]}.

On the Bitcoin side, the competing approaches are the base-layer defenses already surveyed, plus one option deliberately out of scope here. The deferred on-chain answer -- privacy coins such as Zcash and Monero, which rebuild confidentiality directly into consensus rather than bolting it onto a transparent ledger -- is a separate story, covered in its own post.

Every one of these approaches, on both sides, is measured the same way: by the linkage it prevents and against whom. And every one of them runs into the same ceiling, one that no amount of cleverness can engineer away -- the size of the crowd and the strength of the adversary.

8. The Anonymity Set and the Cost of Unlinkability#

There is a ceiling on all of this, and it is not a matter of better engineering.

Recall that anonymity is unlinkability within a set. That set -- the crowd of subjects you could be confused with -- is the anonymity set, and it caps everything. Suppose an adversary has narrowed you to a crowd of $k$ genuinely indistinguishable subjects. With nothing to tell them apart, the adversary's best move is a uniform guess, so the probability of correctly re-identifying you is

$\Pr[\text{re-identify}] \le \frac{1}{k}.$

This is the k-anonymity model formalized by Latanya Sweeney ^[38], and the direction of the inequality is the whole point: $1/k$ is a protection ceiling, not a floor. It is the best privacy the crowd can offer. Real adversaries never do worse than a uniform guess and usually do much better, because any side information -- a timing correlation, an amount, a reused identifier -- only pushes their odds up toward 1. No cryptography can push the ceiling any higher than crowd size $k$ allows; the most a clever scheme can do is help you actually reach the $1/k$ the crowd permits.

And the crowd collapses alarmingly fast, driven not by names but by ordinary attributes. Sweeney's companion result found that just three demographic fields -- 5-digit ZIP code, sex, and date of birth -- uniquely identify about 87% of the United States population, roughly 216 million of 248 million people ^[39]. ※ The same study found about 53% are unique on {place, sex, date of birth} and about 18% on {county, sex, date of birth} ^[39]. Coarsen the location and the crowd grows; sharpen it and the crowd vanishes. Either way, no name is involved. Three innocuous attributes, no name anywhere, and the anonymity set for most people is a set of one. That is linkage by auxiliary attribute -- the exact mechanism the taxonomy predicts and the exact mechanism chain analysis exploits.

The Privacy Pass architecture states the same law in a different vocabulary: stacking attestations shrinks the anonymity set, so every additional signal an adversary can pin to you shrinks the crowd you hide in ^[33]. The ceiling is universal.

Two further limits complete the picture. The first is the impossibility, now stated with its scope: for a single reusable credential shown repeatedly, multi-show unlinkable selective disclosure requires zero knowledge. BBS pays that price and lands unlinkable; the mdoc and SD-JWT baselines refuse it and remain linkable -- not merely un-optimized, but on the wrong side of a theorem ^[22]. Batch issuance and pairwise identifiers reach a different unlinkability by changing the architecture, and stay outside the theorem's scope ^[28].

The second is the transparent-ledger corollary: if every input, output, and amount is globally visible and permanent, linkage channels exist by construction, so a public ledger cannot provide subject-unlinkability natively ^[7]. It can only add unlinkability -- by mixing, by counterparty participation, by fresh-output derivation -- never assume it. The identity domain can build the property into the credential; the ledger can only ever bolt it on.

Same theorem, two readings. A transparent ledger can only bolt unlinkability on, channel by channel, bounded below by the anonymity set and above by the residual leaks it cannot close. The identity domain can build unlinkability in, at the zero-knowledge price the impossibility demands. Either way the property being bought is unlinkability, never namelessness -- and either way it is capped by the size of the crowd.

If the theory is this settled, why is the world still full of linkable systems? Because settled theory does not stop linkage from finding new channels -- and it keeps finding them.

9. Where Linkage Keeps Finding New Channels#

The taxonomy is settled. The fight is not. Every open problem below is the same story -- a new channel through which actions get linked -- wearing new clothes.

The network layer bypasses every on-chain defense. CoinJoin, PayJoin, and Silent Payments all operate on the ledger, but a transaction first travels the peer-to-peer network, and the originating node's IP address, connection timing, and propagation pattern are their own linkage channel. Countermeasures like Dandelion-style transaction relay and routing over Tor address this layer ^[9], but it remains a separate, active front: perfect on-chain unlinkability with a leaky network layer is not unlinkability at all.

Amounts still correlate. A transparent ledger reveals every value. Even when addresses are unlinkable, distinctive amounts, timing, and round-number payments let an analyst stitch flows back together statistically ^[9]. This is why serious systematizations of the field treat amount confidentiality as a distinct, unsolved base-layer problem ^[40].

The base-layer defenses have open theory of their own. Provably-secure collaborative variants of Silent Payments remain open, and private light-client scanning is explicitly flagged as unresolved: a light client cannot watch a static output, so it must scan every transaction or trust a third party with its scan key ^{[41, 20]}. The defining cost of the base layer's best receiver-unlinkability is still unpaid for lightweight users.

The deployment gap is the identity twin of Bitcoin's design-versus-leak gap. The impossibility is settled and BBS is standardized, yet the shipping baselines -- mdoc and SD-JWT VC -- remain linkable by default, and DAA's relying-party path was never built. Requirement outruns deployment on both sides, which is exactly the gap the EU wallet framework is now actively evaluating BBS to close ^[28].

Post-quantum unlinkability is unsolved. The pairing assumptions behind BBS and the blinding behind OPRF tokens both fall to a large quantum computer; the BBS draft itself flags that its security is not post-quantum ^[22]. The unlinkability toolkit will need rebuilding on post-quantum foundations, and the constructions that give multi-show unlinkability cheaply do not yet exist.

None of these is a reason to despair. Each is a line item -- a channel to name, a crowd to size, an adversary to specify. That is not a lament; it is a checklist. And a checklist is exactly what a practitioner needs.

10. Reasoning About Linkability#

Delete the word "anonymous" from your engineering vocabulary. It is a marketing adjective that hides the only questions that matter. Replace it with three.

Run the two domains through that frame. On-chain, the tool follows the goal. To receive many payments to one reusable handle without interaction, use Silent Payments -- but remember it leaves your sender side, your amounts, and your network layer exposed ^[20]. To break co-spend clustering, join a CoinJoin and borrow a crowd -- but watch for toxic change and detectable equal outputs ^[19]. To quietly degrade analysis on an everyday payment, use PayJoin -- accepting that its per-event anonymity set is only two ^[13]. None of the three closes the amount or network channels; they are composed, not chosen.

In the identity domain, the rule is sharper. If you need multi-show unlinkability for one reusable credential, you need BBS, because selective disclosure alone does not deliver unlinkability -- a stable issuer signature links every showing ^{[22, 21]}. If your architecture allows it, batch issuance or pairwise identifiers buy a different unlinkability more cheaply ^{[28, 29]}. For anonymous anti-abuse tokens, reach for OPRF-based Privacy Pass, and remember that stacking attestations shrinks your crowd ^{[32, 33]}.

Run any system -- a wallet, a credential, a login flow -- through those three questions and the five pitfalls, and the taxonomy stops being philosophy. It becomes a checklist you can actually apply.

11. The Same Confusion in Seven Disguises#

Every stubborn myth about "anonymous" systems is one confusion wearing different clothes: a name mistaken for a link. Here are the seven you will meet most often.

Same Theorem, Two Readings#

Return to the men with no names -- the users in the 2013 study who did everything the folklore advised, used fresh addresses, attached no identity, and were deanonymized anyway. Set them beside Chaum's 1981 mix network, and the two scenes are suddenly legible as one story told from opposite ends. Chaum started from unlinkability and built a system to preserve it. Bitcoin started from namelessness and discovered, in its own founding text, that it had preserved the wrong thing.

That is the argument, now proved twice. The transparent ledger is the negative proof: hand every user unlimited fresh pseudonyms and they are still linked -- by co-spending, by change, by amounts, by the network -- because a public ledger cannot stop linkage by construction. The credential toolkit is the constructive proof: engineers who wanted the missing property had to build it on purpose, and they learned it has a price -- zero knowledge for a reusable credential, blinding for a token, a changed architecture for pairwise identifiers and batch issuance. Neither world ever succeeded by hiding a name, and neither ever could, because the property in question was never namelessness.

Pfitzmann and Hansen wrote the resolution years before the arms race that would need it: anonymity is the unlinkability of a subject to its actions within an anonymity set. The blockchain and the credential wallet are two readings of that single theorem. One shows what happens when a system delivers pseudonyms and cannot deliver unlinkability. The other shows what it costs to engineer unlinkability directly. Both point at the same sentence, and it is worth keeping where you can reach it:

Anonymity is the absence of linkability, not the absence of names -- and Bitcoin is the largest live proof of the gap.