The coercion problem in privacy pools

Understand what a privacy pool does and does not protect, why physical coercion (the "$5 wrench attack") is a threat the cryptography alone cannot answer, and how the source paper frames coercion deniability as a placement question: where in the stack should resistance to coercion live?

Track

Research

Module

5 · Research case studies

Prerequisites

What is a zero-knowledge proof · Hash functions · Merkle trees

A privacy pool is a smart contract that breaks the on-chain link between a deposit and a later withdrawal. You deposit a fixed denomination; the contract stores a commitment to your note in a Merkle tree. Later you withdraw by proving, in zero knowledge, that your note is one of the committed leaves under the current root — without revealing which one. To stop you spending the same note twice, the withdrawal publishes a nullifier (a value derived from the note secret) that the contract records; a second withdrawal with the same nullifier is rejected.

This gives withdrawal privacy: an observer who sees every transaction cannot tell which deposit funded which withdrawal, beyond the anonymity set of all deposits sharing that denomination. Compliant variants add a "proof of innocence" — the user additionally proves membership in an approved (clean) set without revealing which commitment is theirs, so privacy and policy can coexist.

The source paper builds on standard, named primitives rather than inventing cryptography. It assumes a Groth16 zk-SNARK: succinct, non-interactive proofs with constant verification cost, at the price of a per-circuit trusted setup. Commitments and the Merkle tree use the Poseidon hash, chosen for its low in-circuit cost. The withdrawal proves membership of a committed note under the verified root and publishes a nullifierHash to prevent double-spending without revealing which deposit is being spent.

Commitment

A hash of a note's secret material, inserted into the Merkle tree on deposit. It hides the note while binding the depositor to it.

Nullifier / nullifierHash

A value derived from the note secret, published on withdrawal and recorded on-chain. It is the spend identifier: the contract's double-spend check is keyed on it. This keying is central to the paper's later negative result.

Proof of innocence

A zero-knowledge proof that the spent note belongs to an approved association set, letting a user demonstrate compliance without deanonymizing.

One point the paper is careful about: the contract's spend test is keyed on the nullifierHash, treated as an identifier. The cryptography (the proof system and the hash) behaves correctly; the interesting failures live in the contract's accounting over those identifiers, which Lesson 2 examines.

The paper augments the standard privacy-pool adversary with physical coercion. The baseline adversary observes all on-chain data, may operate relayers, and knows the full protocol specification — including that a wallet-layer decoy may exist. The augmentation: the adversary can compel the user, in person, to execute a withdrawal and to disclose a credential the user admits to holding. This is the colloquial "$5 wrench attack" — the attacker does not defeat the math, they coerce the human.

The paper names four security goals and keeps them distinct: (i) value safety — no party can withdraw more than was deposited; (ii) withdrawal privacy — withdrawals are unlinkable to deposits up to the anonymity set; (iii) compliance — a user can prove membership in an approved set without deanonymizing; and (iv) coercion deniability — under duress the user surrenders one credential that yields a valid, credible withdrawal while other funds stay untouched and no protocol-introduced link is exposed.

The paper is explicit that plausible deniability holds only within bounds. It holds while the adversary obtains only the admitted (decoy) credential; the real secret is an additional secret the user can deny exists. A memory-hard key derivation makes merely possessing the device insufficient.

The guarantee DEGRADES, the paper says, if the adversary can (a) compel disclosure of all passphrases, (b) inspect the full device derivation state, (c) correlate the two deposits via operational metadata — timing, funding source, relayer, amount, network fingerprint — or (d) control the funding source. Avoiding (c)–(d) is a requirement on the wallet, not a property the protocol enforces. The metadata caveat is stated once and not re-litigated per claim.

This matters because it keeps the contribution honest. The paper does not claim to beat a torturer with unlimited reach; it claims a specific, bounded property and names exactly where that property stops holding.

The paper's framing is that coercion resistance is "often answered in the wrong place." Prior coercion-resistance work exists — fake-credential schemes in electronic voting — but those assume a trusted coordinator and an interactive setting, and the paper argues they do not transfer directly to non-interactive financial withdrawals. So the central question is architectural: where in the stack should resistance to physical coercion live?

Two candidate answers frame the rest of the case study. One builds a decoy spending path into the withdrawal circuit itself (the in-protocol answer, which Lesson 2 shows is unsound). The other moves deniability off the spend path, to the wallet (Lesson 3). The paper's thesis is that the choice between them is forced by a value-safety argument, not a matter of taste.

Expected direction: On-chain unlinkability defeats an observer who reads the chain, but a coercing adversary does not need to read anything: they compel the holder in person to execute a withdrawal or hand over a credential, so the cryptography is simply bypassed. The relevant goal is coercion deniability (goal iv), and only in the limited sense of PLAUSIBLE deniability: the user surrenders one credible decoy credential while other funds stay untouched. It holds only while the adversary gets just that credential and cannot compel all secrets, inspect the device, or correlate the deposits via operational metadata.

What does a privacy pool protect against, and what does it not?

It protects withdrawal privacy against an on-chain observer by severing the deposit-withdrawal link via a ZK membership proof and a nullifier. It does not protect against physical coercion of the holder, which bypasses the cryptography entirely.

What is the role of the nullifierHash, and why will it matter later?

It is the spend identifier the contract's double-spend check is keyed on. The paper's negative result is about the contract's accounting over these identifiers, not about the proof system or hash.

Is the paper's coercion deniability absolute?

No. It is plausible deniability, bounded by anonymity-set size and operational metadata, and it degrades if the adversary compels all passphrases, inspects the device state, or controls/correlates the funding and timing.