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

> Pseudonymity gives you a name-free identifier; anonymity gives you unlinkability. Bitcoin's transparent ledger is the largest live proof they are not the same.

*Published: 2026-07-19*
*Canonical: https://paragmali.com/blog/pseudonymous-was-never-anonymous-what-bitcoins-transaction-g*
*© Parag Mali. All rights reserved.*

---
<TLDR>
Pseudonymity gives you a name-free identifier; anonymity gives you unlinkability -- an observer's inability to tie two of your actions to the same subject within a crowd. These are different properties, and Bitcoin is the largest live proof of the gap: it hands every user unlimited fresh addresses and still deanonymizes them, because a transparent ledger cannot stop those addresses from being linked. The identity-domain cryptographers learned the lesson decades earlier and engineered unlinkability directly -- anonymous credentials, BBS signatures, blinded tokens, anonymous attestation -- but only by paying the zero-knowledge price. Same theorem, read from both sides: anonymity is the absence of linkability, not the absence of names.
</TLDR>

## 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* [@meiklejohn-2013] -- 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 [@ron-shamir-2013]; Fergal Reid and Martin Harrigan had shown two years earlier that the public graph alone links addresses [@reid-harrigan-2011]. 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:

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

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 [@chaum-1981]. 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 [@chaum-1982]. 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* [@chaum-1985], 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.<Sidenote>"Satoshi Nakamoto" is itself a pseudonym whose holder remains unknown -- the author of the pseudonymity model is, fittingly, its own best example.</Sidenote> 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 [@nakamoto-2008]. 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" [@nakamoto-2008]. 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.

<Mermaid caption="Two lineages of privacy engineering. The identity lineage set out to hide linkage; the ledger lineage set out to hide names. Both run to 2026.">
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
</Mermaid>

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 [@pfitzmann-hansen-2010]. Its definitions are careful, and the care is the point. Start with the one that does the heavy lifting.

<Definition term="Unlinkability">
Two or more items of interest (messages, actions, transactions, identifiers) are unlinkable if an attacker who observes the system cannot sufficiently distinguish whether those items are related. Linkability is defined relative to a specific attacker and a specific set of actions -- it is never absolute [@pfitzmann-hansen-2010].
</Definition>

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

<Definition term="Anonymity set">
The set of subjects among whom a given subject cannot be distinguished. To have anonymity at all, there must be an appropriate set of possible subjects -- a crowd. Anonymity is never stronger than that crowd is large [@pfitzmann-hansen-2010].
</Definition>

<Definition term="Anonymity">
The non-identifiability of a subject within an anonymity set. Equivalently, and this is the load-bearing phrasing: anonymity is the unlinkability of a subject with respect to an item of interest -- the observer cannot link the action to the actor among the crowd of possible actors [@pfitzmann-hansen-2010].
</Definition>

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.

<Definition term="Pseudonymity">
The use of pseudonyms as identifiers. A pseudonym is a name-free identifier for a subject. Pseudonyms live on a spectrum: from persistent (one long-lived handle) to one-time or transaction pseudonyms (a fresh identifier per action) [@pfitzmann-hansen-2010].
</Definition>

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.

> **Note:** A fresh Bitcoin address is a transaction pseudonym. Co-spend it once, or let a wallet route change through it, and it becomes a persistent pseudonym -- a durable identifier for one owner. Nothing about the name changed. The linkability did.

| Property | What it gives you | What it hides | What defeats it |
|---|---|---|---|
| Pseudonymity | A stable, name-free identifier | Your legal name | Linking the pseudonym to you, or to your other pseudonyms |
| Unlinkability | Two actions cannot be tied to one subject | The relation between items of interest | Any correlating channel the adversary can observe |
| Anonymity | Non-identifiability within a crowd | Which member of the set acted | Shrinking the crowd toward one, by any handle |

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.

<Mermaid caption="How the three properties relate. Anonymity is built from unlinkability within an anonymity set. Pseudonymity is orthogonal: a pseudonym is anonymous only while it stays unlinkable.">
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&#123;"Is the pseudonym linkable?"&#125;
    E -->|"reused or co-spent"| F["Collapses to a persistent, attributable identity"]
    E -->|"unlinkable across actions"| G["Approaches anonymity within the set"]
</Mermaid>

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](/blog/secure-against-whom-the-security-definitions-every-protocol-/), across which actions, within which anonymity set?* Hold that question; it becomes the practitioner's checklist at the end.

> **Key idea:** 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.

<Definition term="UTXO (Unspent Transaction Output)">
Bitcoin has no account balances. It has coins, called unspent transaction outputs. A transaction consumes one or more existing UTXOs as inputs and creates new UTXOs as outputs, each locked to an address. To spend a UTXO you sign with the key for its address. Your "balance" is just the set of UTXOs you can currently sign for [@btc-wiki-privacy].
</Definition>

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.

<Definition term="Common-Input-Ownership Heuristic (CIOH)">
The presumption that if a transaction spends multiple inputs, all of those inputs are controlled by a single entity -- because signing them all requires holding every corresponding key. It is the core clustering move of all Bitcoin deanonymization [@meiklejohn-2013].
</Definition>

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 [@reid-harrigan-2011]. 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 [@meiklejohn-2013].

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

<PullQuote>
"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 [@nakamoto-2008]
</PullQuote>

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.<Sidenote>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 [@unionfind-wiki].</Sidenote> 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.

<RunnableCode lang="js" title="Common-input-ownership clustering: co-spent inputs collapse fresh addresses into entities">{`
// 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(', '));
`}</RunnableCode>

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.

<Mermaid caption="How co-spent inputs and detected change fuse fresh addresses into one named entity. CIOH unites the inputs; change detection chains the cluster forward through later transactions.">
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
</Mermaid>

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

<Definition term="Change output">
The output that returns a spend's remainder to the payer. Wallets almost always send change to a fresh, one-time address -- which is exactly what makes it detectable and chainable: identify which output is change, and you have found the payer's next address, extending the cluster into the future [@btc-wiki-privacy].
</Definition>

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 [@meiklejohn-2013].
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 [@bip78-2019].
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 [@bip78-2019].
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 [@btc-wiki-privacy].
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 [@btc-wiki-privacy].

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*.

> **Note:** The single most common Bitcoin privacy mistake is believing a new address per payment anonymizes you. It does not. The next time your wallet co-spends two of those fresh addresses (CIOH) or routes change through one (change detection), they re-link -- with no name revealed and no key broken. Namelessness was never the missing property.

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 [@btc-wiki-addrreuse]. 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.

<Aside label="The legal front of the arms race">
Centralized mixers failed not on mathematics but on trust and law. The operator of the Helix mixer pleaded guilty to laundering more than \$300 million in bitcoin, a case whose public record is the clearest evidence that "give a third party custody and hope" is a dead end, not a privacy technique [@doj-helix]. The lesson pushed the field toward *trustless* mixing, where no operator ever holds your coins or learns the mapping.
</Aside>

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 [@btc-wiki-coinjoin].<MarginNote>Gregory Maxwell sketched the idea in a 2013 forum thread bluntly titled "I taint rich!" before the canonical write-up [@bitcointalk-taintrich].</MarginNote> Maxwell's 2013 proposal made this practical [@maxwell-coinjoin-2013], and modern coordinators such as WabiSabi refined it [@optech-coinjoin]. 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 [@bip78-2019]. 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 [@bip352-2023].

| Gen | Attack: a new way to *link* | Defense that answered it | Why the next generation was forced |
|---|---|---|---|
| 0 | Fresh pseudonyms per transaction | Address rotation, HD wallets [@btc-wiki-addrreuse] | Co-spends and change re-link fresh addresses |
| 1 | Common-input-ownership clustering [@reid-harrigan-2011] | Centralized mixers -- a dead end [@doj-helix] | Custody enables theft, logging, prosecution |
| 2 | Change detection and entity tagging [@meiklejohn-2013] | CoinJoin [@maxwell-coinjoin-2013] | Equal outputs are detectable; toxic change remains |
| 3 | Whole-graph taint and flow [@ron-shamir-2013] | PayJoin / BIP 78 [@bip78-2019] | Needs a subtler, invisible degradation of analysis |
| 4 | Industrial chain analysis [@meiklejohn-2013] | Silent Payments / BIP 352 [@bip352-2023] | Every prior defense still leaked the receiving address |

<Mermaid caption="Attack and defense in lockstep. Each base-layer defense answers one specific linkage channel of the matching attack generation -- never a name.">
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
</Mermaid>

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.

<PullQuote>
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 [@chaum-1985]
</PullQuote>

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.

<Definition term="Selective disclosure">
Revealing only a chosen subset of a credential's signed attributes while withholding the rest -- for example, proving you are over 18 from a signed birth date without revealing the date, name, or document number [@openid4vp-1.0].
</Definition>

<Definition term="Multi-show unlinkability">
The property that repeated presentations of the same credential cannot be correlated to one another -- two verifiers, even colluding, cannot tell they saw the same holder [@bbs-draft10-2026].
</Definition>

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 [@cl-2001]. A [zero-knowledge proof](/blog/the-discrete-log-held-the-proofs-leaked-a-field-guide-to-com/) 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](/blog/the-age-gate-that-doesnt-know-your-age-how-anonymous-credent/), later rebuilt on bilinear pairings for compactness [@cl-2004-bilinear], which is where the modern short signatures enter.

<Sidenote>Naming discipline matters here. "BBS" is the current IRTF CFRG scheme in `draft-irtf-cfrg-bbs-signatures` [@bbs-draft10-2026]; "BBS+" is the 2006 Au-Susilo-Mu variant [@bbsplus-2006]; and both names trace to Boneh, Boyen, and Shacham's 2004 "Short Group Signatures" [@bbs-2004]. They are related but distinct -- do not use them interchangeably.</Sidenote>

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](/blog/direct-anonymous-attestation-the-zero-knowledge-proof-alread/), standardized into the TPM in 2004, applied the same idea to hardware attesting to its own genuineness without a serial number [@daa-2004]. The mechanism, in one picture:

<Mermaid caption="A BBS presentation. The issuer signs an attribute block once; the holder never shows the signature, only fresh zero-knowledge proofs. Two showings cannot be correlated, even by colluding verifiers.">
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
</Mermaid>

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.

<RunnableCode lang="js" title="Selective disclosure is not unlinkability: a stable issuer signature links two presentations">{`
// 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)');
`}</RunnableCode>

> **Note:** Selective disclosure without the zero-knowledge price stays linkable, exactly as fresh-but-co-spent Bitcoin addresses do. The correlating handle is not the disclosed data -- it is the stable cryptographic object carried across presentations. Hide the name all you like; the link survives.

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.

> **Key idea:** 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 [@eudi-arf-zkp, @nist-800-63c].

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" [@w3c-vc-di-bbs], and the European Union's digital-identity architecture is actively evaluating BBS against a legal unlinkability mandate [@eudi-arf-zkp]. 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 [@bbs-draft10-2026]. That is a first-class, spec-level property, not a footnote. A reference implementation proves it is buildable [@bbs-refimpl], and it is being evaluated in standards and pilots: the W3C Data Integrity cryptosuite for BBS [@w3c-vc-di-bbs] and the EU digital-identity framework's zero-knowledge evaluation against a statutory unlinkability requirement [@eudi-arf-zkp].

The second tool is cheaper and already ubiquitous: blinded tokens built on [oblivious pseudorandom functions](/blog/the-server-helped-and-never-saw-a-field-guide-to-oblivious-p/).

<Definition term="Oblivious Pseudorandom Function (OPRF)">
A two-party protocol computing a pseudorandom function PRF(k, x) where the client learns the output but not the key k, and the server learns neither the input x nor the output. Blinding the input is what makes the resulting token unlinkable to its issuance -- the primitive behind Privacy Pass [@rfc9497-2023].
</Definition>

An OPRF (and its verifiable variant, the VOPRF) lets a server issue a token it cannot later recognize, so redemption is unlinkable to issuance [@rfc9497-2023]. 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 [@rfc9576-2024]. 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.

<Aside label="Designed-for is not deployed-at-scale">
DAA is a beautiful design: a TPM proves it is a genuine, certified part without revealing which chip it is, and the scheme supports basename-scoped pseudonyms so attestations are linkable within a context and unlinkable across contexts [@daa-2004]. But designed-for is not deployed-at-scale. As of 2026, the elliptic-curve DAA profile remains optional in the TPM 2.0 library specification [@tcg-tpm2-spec], consumer TPM vendors largely do not enable it, and the relying-party path -- the browser or server side that would challenge a TPM for an anonymous attestation -- was, as far as any public deployment shows, never built out: the WebAuthn standard, which once specified an ECDAA attestation format, removed it for lack of adoption [@webauthn-ecdaa-removal]. Treat DAA as proof that unlinkability can be designed into hardware, not as evidence it ships at scale.
</Aside>

<Sidenote>The basename dial is worth savoring: pick one basename and all attestations under it are linkable to each other but to nothing outside it. Unlinkability here is a tunable scope, not an on-off switch -- exactly the "against whom, across which actions" framing the taxonomy demands [@daa-2004].</Sidenote>

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](/blog/two-standards-bodies-one-presentation-protocol-how-iso-and-o/). Both make selective disclosure mandatory. Neither makes you unlinkable.

<Aside label="When the requirement outruns the deployment">
This is the identity-domain twin of Bitcoin's design-versus-leak gap. ISO/IEC 18013-5 and the OpenID presentation profile *require* unlinkability as a goal -- OpenID4VP devotes a privacy section to verifier-to-verifier unlinkable presentations [@openid4vp-1.0] -- yet the baseline mdoc and SD-JWT VC formats do not themselves deliver it: a device-bound key reused across presentations, or a stable issuer signature, is trivially correlatable [@iso-18013-5-2021, @openid4vp-1.0]. Selective disclosure alone never yields unlinkability. Closing the gap needs conscious mechanisms -- BBS proofs, pairwise identifiers, or batch issuance -- the same shape of fix Bitcoin needs at its base layer.
</Aside>

| Dimension | BBS (IRTF CFRG draft-10) | OPRF -- Privacy Pass | DAA (design-purpose) | mdoc / SD-JWT baseline |
|---|---|---|---|---|
| Unlinkability property | Multi-show unlinkable presentations | Issuance-to-redemption, one-or-limited-show | Cross-basename unlinkable attestation | None by default (stable signature links) |
| Selective disclosure | Yes, per-attribute | No (opaque token) | Attribute-limited | Yes, but linkable |
| Pays the ZK price? | Yes (proof of a signature) | Partial (blinding) | Yes | No -- hence linkable |
| Crypto basis | Pairings (BLS12-381) | Prime-order group | Pairing / RSA-DAA | Plain signatures + hashes |
| Deployment (2026) | Emerging (VC cryptosuites, pilots) | At scale (anti-abuse tokens) | Effectively unshipped | Baseline but linkable-by-default |
| Best suited for | One credential shown to many verifiers unlinkably | Anonymous rate-limit / anti-abuse | Illustrating designed-in hardware unlinkability | Interop today when unlinkability is not required |

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 [@optech-coinjoin]. PayJoin quietly poisons both common-input-ownership and change detection inside an ordinary-looking payment [@bip78-2019]. 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 [@bip352-2023].

<Sidenote>The identity toolkit even quietly powers a Bitcoin defense: WabiSabi's CoinJoin coordinator uses keyed-verification anonymous credentials to enforce that inputs equal outputs without learning the input-to-output mapping -- unlinkable credentials protecting an on-chain protocol [@optech-coinjoin].</Sidenote>

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 [@bip352-2023].

<Mermaid caption="Silent Payments derivation. The sender turns an ECDH shared secret into a unique per-payment output; the receiver scans and recomputes the same secret to detect it. No two payments to one receiver are linkable.">
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
</Mermaid>

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):

<RunnableCode lang="js" title="Silent Payments: sender and receiver derive the same ECDH shared secret">{`
// 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);
`}</RunnableCode>

| Dimension | CoinJoin / WabiSabi | PayJoin / BIP 78 | Silent Payments / BIP 352 |
|---|---|---|---|
| Linkage channel attacked | Common-input-ownership (falsified) | CIOH plus change detection (poisoned) | Receiving-address linkage (removed) |
| Interaction model | Synchronous multi-party round | Interactive two-party payment | Non-interactive static address |
| Anonymity set per event | Count of equal-valued participants | 2, with network-wide doubt | 1 output per payment, cross-payment unlinkable |
| On-chain footprint | Detectable equal outputs | Blends in as an ordinary payment | Blends in as an ordinary taproot output |
| Dominant cost | Coordination and liquidity | Both parties online | Receiver ECDH scan per transaction |
| Residual leak | Toxic change, amounts, timing | Per-event set only 2 | Sender side and amounts remain |
| Status (2026) | Active (Wasabi 2.0, JoinMarket) | Deployed | Complete, base-layer SOTA |

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 [@rfc9497-2023].

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 [@nist-800-63c] -- and the EU wallet framework treats per-relying-party pseudonyms (for instance via WebAuthn) as a way to ensure unlinkability across verifiers [@eudi-arf-pseudonyms]. 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 [@eudi-arf-zkp].

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

| Approach | Unlinkability bought | Price | Relative to the single-credential theorem |
|---|---|---|---|
| BBS | Multi-show, multi-attribute | Zero knowledge + pairings | Inside: pays ZK, lands unlinkable |
| OPRF tokens | One-or-limited-show | Blinding (cheap) | Outside: not multi-show selective disclosure |
| Pairwise identifiers | Per-verifier (RP-vs-RP) | Correct issuance; trust the issuer | Outside: issuer still links; architecture changed |
| Batch issuance | Multi-show, fresh per show | Storage and reissuance | Outside: a single-use object each show |

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 [@eudi-arf-zkp, @nist-800-63c].

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 [@sweeney-2002], 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 [@sweeney-2000].<MarginNote>The same study found about 53% are unique on &#123;place, sex, date of birth&#125; and about 18% on &#123;county, sex, date of birth&#125; [@sweeney-2000]. Coarsen the location and the crowd grows; sharpen it and the crowd vanishes. Either way, no name is involved.</MarginNote> 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 [@rfc9576-2024]. 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* [@bbs-draft10-2026]. Batch issuance and pairwise identifiers reach a *different* unlinkability by changing the architecture, and stay outside the theorem's scope [@eudi-arf-zkp].

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 [@nakamoto-2008]. 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.

> **Key idea:** 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 [@btc-wiki-privacy], 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 [@btc-wiki-privacy]. This is why serious systematizations of the field treat amount confidentiality as a distinct, unsolved base-layer problem [@bonneau-sok-2015].

**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 [@optech-silentpay, @bip352-2023]. 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 [@eudi-arf-zkp].

**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 [@bbs-draft10-2026]. The unlinkability toolkit will need rebuilding on post-quantum foundations, and the constructions that give multi-show unlinkability cheaply do not yet exist.

<Aside label="Legal pressure moved past custody">
The legal pressure that ended custodial mixing has not relented; it has widened. The custodial dead end traced in section 4 was only the first front, because a transparent ledger forces privacy to be *added* by some coordinating party, and that party can always be named. So the exposure does not stop at custody: even *coordinator-run* trustless mixing, where no operator ever holds user funds, still leaves a coordinator in the frame. On a public ledger, privacy is contested in courtrooms as much as in code, and this front has not closed.
</Aside>

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.

> **Note:** Before choosing any privacy mechanism, answer: **unlinkable against whom** (which adversary, with what view of the system), **across which actions** (which specific items of interest must not be tied together), and **within which anonymity set** (how large is the crowd you hide in, and what shrinks it)? A mechanism that cannot answer all three is not a privacy solution -- it is a slogan.

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 [@bip352-2023]. To break co-spend clustering, join a CoinJoin and borrow a crowd -- but watch for toxic change and detectable equal outputs [@optech-coinjoin]. To quietly degrade analysis on an everyday payment, use PayJoin -- accepting that its per-event anonymity set is only two [@bip78-2019]. 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 [@bbs-draft10-2026, @openid4vp-1.0]. If your architecture allows it, batch issuance or pairwise identifiers buy a different unlinkability more cheaply [@eudi-arf-zkp, @nist-800-63c]. For anonymous anti-abuse tokens, reach for OPRF-based Privacy Pass, and remember that stacking attestations shrinks your crowd [@rfc9497-2023, @rfc9576-2024].

| Your goal | Reach for | Residual leak to watch |
|---|---|---|
| Receive to a reusable handle, no interaction | Silent Payments (BIP 352) | Sender-side clustering, amounts, network layer |
| Break co-spend clustering with a crowd | CoinJoin / WabiSabi | Toxic change, detectable equal outputs, timing |
| Quietly degrade analysis on a payment | PayJoin (BIP 78) | Per-event set of only two |
| Show one credential to many verifiers unlinkably | BBS | Pairing and ZK cost; per-proof randomness must be sound |
| Anonymous rate-limit or anti-abuse token | OPRF / Privacy Pass | One-or-limited-show; attestation stacking shrinks the crowd |
| Avoid verifier-to-verifier correlation without ZK | Pairwise identifiers or batch issuance | Issuer still links (pairwise); storage and reissuance (batch) |

<Spoiler kind="hint" label="The five linkage pitfalls that quietly re-identify people">
1. **Address reuse** -- turns a transaction pseudonym into a persistent one; the original sin.
2. **Toxic change** -- a CoinJoin output that later merges with a labeled coin re-links the whole set.
3. **Stable-issuer-signature reuse** -- selective disclosure with a fixed signature is a reused address in credential form.
4. **Per-proof randomness failure** -- a BBS or ZK proof with a repeated or predictable nonce leaks the correlation the proof was meant to hide.
5. **Attestation stacking** -- each extra token or attribute you present shrinks your anonymity set toward one.
</Spoiler>

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.

<FAQ title="Misconceptions about anonymity and unlinkability">
<FAQItem question="Isn't Bitcoin anonymous?">
No. Bitcoin is pseudonymous, and the whitepaper only ever claimed that. It is the most transparent financial ledger ever built -- every payment public, permanent, and globally replicated -- and fresh, name-free addresses are routinely linked into named clusters using nothing but the public graph [@meiklejohn-2013, @nakamoto-2008].
</FAQItem>
<FAQItem question="Doesn't a new address for every transaction make me anonymous?">
No. The next time your wallet co-spends two of those addresses, common-input-ownership links them; the next time it makes change, change detection chains them forward. The fresh addresses re-link with no name revealed and no key broken [@btc-wiki-privacy].
</FAQItem>
<FAQItem question="Doesn't selective disclosure give me privacy?">
Only field-hiding, not unlinkability. A stable issuer signature carried across two presentations links them, whatever fields you hid. Multi-show unlinkability needs zero knowledge (BBS) or an architecture that never reuses one credential -- pairwise identifiers or batch issuance [@openid4vp-1.0, @bbs-draft10-2026, @eudi-arf-zkp].
</FAQItem>
<FAQItem question="Doesn't a mixer make my coins untraceable?">
A custodial mixer relocates the linkage to an operator who can log it, steal the funds, or be prosecuted -- the Helix operator pleaded guilty to laundering more than \$300 million. Trustless CoinJoin is better but only degrades specific heuristics and leaves toxic change behind [@doj-helix, @optech-coinjoin].
</FAQItem>
<FAQItem question="Isn't pseudonymous the same as anonymous?">
No, and that is the whole point of this article. A pseudonym is a name-free identifier; anonymity is unlinkability within a crowd. A persistent, linkable pseudonym is the opposite of anonymous -- it is a durable handle that tracks you [@pfitzmann-hansen-2010].
</FAQItem>
<FAQItem question="Does Tor or a VPN fix on-chain linkage?">
No. Those protect the network layer, which is a separate and still-open channel. On-chain co-spend, change, and amount linkage remain exactly as strong regardless of how the packet was routed [@optech-silentpay].
</FAQItem>
<FAQItem question="Is BBS just a better signature?">
No. Its named, first-class property is unlinkability: the holder derives a freshly randomized zero-knowledge proof so two showings cannot be correlated, paying a pairing-and-zero-knowledge cost that ordinary signatures do not [@bbs-draft10-2026].
</FAQItem>
</FAQ>

## 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:

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

<StudyGuide slug="pseudonymous-was-never-anonymous-what-bitcoin-s-transaction" keyTerms={[
  { term: "Pseudonymity", definition: "The use of a name-free identifier, on a spectrum from persistent to one-time/transaction pseudonyms." },
  { term: "Unlinkability", definition: "An attacker cannot sufficiently distinguish whether two items of interest are related; always relative to an adversary." },
  { term: "Anonymity", definition: "Non-identifiability of a subject within an anonymity set -- the unlinkability of a subject to an item of interest." },
  { term: "Anonymity set", definition: "The crowd of subjects among which a subject cannot be distinguished; unlinkability is no stronger than this crowd is large." },
  { term: "Common-input-ownership heuristic", definition: "The presumption that all inputs of a Bitcoin transaction are controlled by one entity." },
  { term: "Change output", definition: "The remainder a wallet returns to itself, usually to a fresh one-time address, which makes it detectable and chainable." },
  { term: "Selective disclosure", definition: "Revealing only a chosen subset of a credential's signed attributes while withholding the rest." },
  { term: "Multi-show unlinkability", definition: "Repeated presentations of the same credential cannot be correlated to one another." },
  { term: "BBS", definition: "The IRTF CFRG signature scheme delivering multi-show unlinkable selective disclosure via re-randomized zero-knowledge proofs." },
  { term: "k-anonymity ceiling", definition: "From a crowd of k indistinguishable subjects, re-identification succeeds with probability at most 1/k -- a protection ceiling, not a floor." }
]} questions={[
  { q: "Why does a fresh Bitcoin address per payment fail to make you anonymous?", a: "Co-spending inputs (common-input-ownership) and change detection re-link the fresh addresses, with no name revealed and no key broken." },
  { q: "State the definition of anonymity used throughout this article.", a: "The non-identifiability of a subject within an anonymity set -- equivalently, the unlinkability of a subject to an item of interest." },
  { q: "Why is a stable issuer signature a privacy problem in a selective-disclosure credential?", a: "It is a persistent identifier carried across presentations, so it links them just like a reused address; selective disclosure does not remove it." },
  { q: "What is the k-anonymity ceiling, and which way does the inequality point?", a: "From a crowd of k, re-identification succeeds with probability at most 1/k; it is a protection ceiling, and side information only pushes the adversary's odds up toward 1." },
  { q: "When is zero knowledge strictly required for unlinkability?", a: "For a single reusable credential shown repeatedly with selective disclosure; batch issuance and pairwise identifiers avoid it only by changing the architecture." }
]} />