L10: Privacy & Anonymity
The Privacy Paradox: Transparent Ledgers, Exposed Lives
01Bitcoin’s whitepaper described addresses as a privacy mechanism: rather than linking transactions to real identities, users generate fresh public keys for each payment. The implicit promise was pseudonymity — a name replaced by a hash. That promise has not aged well. Every satoshi ever moved on the Bitcoin blockchain is visible in perpetuity to any observer with an internet connection. When an address is linked to a real identity — through an exchange KYC check, a forum post, or a payment receipt — the entire transaction history of that address, and potentially every counterparty it ever touched, becomes retroactively attributable.
This is not merely a theoretical concern. In 2013, the FBI seized the Silk Road marketplace and traced millions of dollars of Bitcoin through the public ledger to identify administrators and vendors. In 2021, the Department of Justice recovered 63.7 Bitcoin from the Colonial Pipeline ransomware attackers by following the transaction graph on-chain — a forensic feat that would have been impossible with cash. The same transparency that enables trustless auditing also enables surveillance at a scale no prior payment system has permitted.
The legitimate reasons for financial privacy are numerous and prosaic. A business does not want competitors reading its payroll data from the blockchain. A domestic violence survivor does not want an abusive ex-partner tracking their financial transactions. A journalist receiving payment from a whistleblower source does not want that relationship exposed. A wealthy individual does not want to broadcast a target to criminals. Privacy is not synonymous with wrongdoing — every major financial system in history has maintained it as a design property.
There is also a subtler economic argument: fungibility. A dollar bill is worth exactly one dollar regardless of where it has previously been. A Bitcoin, by contrast, can be “tainted” by association with a prior criminal transaction. Exchanges scan incoming deposits against blacklists and may freeze coins that passed through sanctioned addresses years ago. If individual units of a currency can be discriminated against based on their history, the currency loses a foundational monetary property. Privacy technologies restore fungibility by severing the transaction graph.
Zero-Knowledge Proofs: Proving Without Revealing
02A zero-knowledge proof (ZKP) is a cryptographic protocol by which one party — the prover — convinces another party — the verifier — that a statement is true, without conveying any information beyond the bare fact of its truth. The canonical illustration: Alice knows the solution to a maze and wants to prove this to Bob without revealing the solution. She enters the maze from one direction while Bob watches the exit. If she consistently emerges on the correct side across many trials, Bob becomes statistically convinced she knows the solution. No information about the solution’s content is transmitted.
For blockchain applications, ZKPs solve a precise problem: how can a node verify that a transaction is valid (inputs cover outputs, no double-spend, correct authorization) without seeing the transaction amounts or addresses? This is not an abstract question — it is the core technical challenge that Zcash’s designers solved with zk-SNARKs in 2016 and that Layer 2 rollups now use to compress thousands of Ethereum transactions into a single on-chain proof.
Completeness — if the statement is true, an honest prover can always convince an honest verifier.
Soundness — if the statement is false, no cheating prover can convince the verifier (except with negligible probability).
Zero-knowledge — the verifier learns nothing beyond the truth of the statement itself.
ZK-SNARKs (Succinct Non-interactive Arguments of Knowledge) produce proofs small enough to fit in a single transaction (typically 200–300 bytes), verify in milliseconds, and require only a single round of communication from prover to verifier. The “non-interactive” property is essential for blockchain use: the verifier does not need to be online at proving time. The trade-off is a trusted setup ceremony: the scheme’s security parameters must be generated by a multi-party computation, and if any single participant in that ceremony is honest (destroys their “toxic waste” contribution), the system is secure. Modern SNARK constructions (Halo2, Plonky2, Nova) eliminate the trusted setup by exploiting polynomial commitment schemes, removing this assumption entirely.
ZK-STARKs (Scalable Transparent Arguments of Knowledge) make a different trade: they require no trusted setup whatsoever and rely only on collision-resistant hash functions (quantum-resistant), but produce proofs that are larger — typically 10–100 kilobytes. StarkWare uses STARKs to scale Ethereum, generating validity proofs for batches of thousands of transactions. The verification cost on Ethereum is a flat gas charge regardless of batch size, making the per-transaction cost asymptotically cheap.
| Property | ZK-SNARK (Groth16) | ZK-SNARK (Halo2) | ZK-STARK |
|---|---|---|---|
| Proof size | ~200 bytes | ~1–3 KB | 10–100 KB |
| Trusted setup | Required | None | None |
| Quantum resistance | No | No | Yes |
| Verification time | Milliseconds | Milliseconds | Seconds |
| Primary use cases | Zcash, Tornado Cash | zkSync Era, Scroll | StarkNet, StarkEx |
Mixers, Tumblers, and Anonymity Sets
03Before cryptographic privacy protocols matured, the primary tool for breaking transaction linkability was mixing: pooling coins from multiple users and returning equivalent amounts to fresh addresses, severing the chain of custody. The idea is conceptually simple and predates blockchain — cash launderers have always used layering techniques to obscure the origin of funds. The blockchain version automates and scales this process, using smart contracts to remove the need for a trusted mixing operator.
A centralised tumbler operates as follows: Alice sends 1 BTC to the tumbler service. The tumbler accepts deposits from many users simultaneously. After a randomised delay, it sends 1 BTC (minus a fee) to an address Alice specifies, drawing from a pool of mixed coins rather than returning her exact coins. The privacy guarantee rests on the anonymity set size — the number of users whose coins are in the pool at any time. If ten users deposit 1 BTC each, an observer cannot determine which output belongs to which input. The critical weakness: the tumbler operator knows everything. Users must trust it not to keep logs.
The privacy guarantee of any mixer is bounded by its anonymity set: the set of deposits indistinguishable from each other. A mixer with one deposit and one withdrawal provides zero privacy. A mixer with 10,000 users who each deposited exactly 1 ETH provides strong privacy, because any given withdrawal could have come from any of those 10,000 deposits. Practical weaknesses erode this guarantee:
- Amount correlation: depositing and withdrawing unusual round amounts narrows the set
- Timing correlation: short delays between deposit and withdrawal narrow the set
- Gas address reuse: if the withdrawal address previously interacted with the deposit address, the link is partially restored
- On-chain behaviour post-withdrawal: sending to an exchange that enforces KYC re-links the identity
Monero and Zcash: Two Philosophies of Privacy
04Two cryptocurrencies have moved privacy from an optional feature to a design constraint: Monero (XMR) and Zcash (ZEC). They represent opposite philosophies about who should control privacy defaults and which cryptographic primitives best deliver them. Understanding both in depth illuminates the fundamental trade-offs between mandatory and optional confidentiality.
Monero launched in 2014 as a fork of Bytecoin, itself based on the CryptoNote protocol. Its guiding principle is that privacy must be mandatory for all participants; optional privacy is weak privacy, because the anonymity set consists only of users who opt in, and opting in is itself a signal. Every Monero transaction deploys three cryptographic layers simultaneously:
Ring Signatures
The sender’s key is mixed with 15 decoy public keys (ring size 16). Any member of the ring could have signed, hiding the true sender even from the decoys themselves.
Stealth Addresses
Recipients publish a single public key. Senders derive a one-time address per transaction using ECDH. Only the recipient can detect and spend from their stealth addresses.
RingCT
Ring Confidential Transactions use Pedersen commitments to hide transaction amounts while still proving that inputs equal outputs and no coins are created from nothing.
The net result: on Monero, the sender is hidden, the receiver is hidden, and the amount is hidden — all by default, for every transaction, with no user action required. This mandatory approach maximises the anonymity set (every transaction in every block is privacy-enabled) but comes at a cost: transaction sizes are substantially larger than Bitcoin equivalents (~1.5–2 KB vs. ~250 bytes), and the cryptographic overhead reduces throughput.
Zcash was launched in 2016 by the Electric Coin Company, founded by Zooko Wilcox, and pioneered the first production deployment of zk-SNARKs in a cryptocurrency. Where Monero hides information through cryptographic obfuscation (decoys), Zcash achieves mathematically provable privacy through zero-knowledge proofs. Zcash has two pools: a transparent pool (functionally identical to Bitcoin, with all addresses and amounts visible) and a shielded pool (where zk-SNARKs prove validity without revealing any information).
The Zcash shielded pool uses Sapling (and now Orchard) addresses prefixed with “zs”. Transactions between shielded addresses reveal only the transaction fee; senders, receivers, and amounts are all hidden by the zk-SNARK. The practical weakness: most Zcash transactions historically used the transparent pool. Privacy in Zcash requires users to actively opt in, and until the Sapling upgrade (2018), generating a shielded transaction took nearly a minute on consumer hardware.
| Property | Bitcoin | Monero (XMR) | Zcash (ZEC, shielded) | Secret Network (SCRT) |
|---|---|---|---|---|
| Sender hidden | No | Yes (ring sigs) | Yes (ZK-SNARK) | Yes |
| Receiver hidden | No | Yes (stealth addr.) | Yes (ZK-SNARK) | Yes |
| Amount hidden | No | Yes (RingCT) | Yes (ZK-SNARK) | Yes |
| Privacy default | No | Mandatory | Optional | Mandatory |
| Smart contracts | Limited | No | No | Yes |
| Tx size overhead | ~250 B | ~1,500 B | ~2,000 B | Varies |
Blockchain Forensics: How Pseudonymity Is Broken
05The privacy technologies above are powerful but not impenetrable. A mature industry of blockchain analytics firms — Chainalysis, Elliptic, CipherTrace (acquired by Mastercard), and TRM Labs — generates hundreds of millions of dollars in annual revenue helping law enforcement and financial institutions trace funds through public ledgers. Understanding their methods is essential both for assessing the real-world privacy properties of different systems and for designing more robust privacy tools.
Clustering heuristics are the foundation of address attribution. The most powerful is the common input ownership heuristic: when a Bitcoin transaction has multiple inputs, the protocol requires that the owner of each input sign the transaction. In practice, users frequently combine inputs owned by the same wallet, so any multi-input transaction is very likely controlled by a single entity. By recursively applying this rule, analysts build clusters of addresses that likely belong to the same wallet. One seed address from a KYC exchange can propagate attribution across thousands of addresses.
Dust attacks (also called dusting) are an active technique: an adversary sends tiny amounts (“dust”) to many target addresses. If the victim consolidates those dust inputs with other UTXOs in a future transaction, the common-input heuristic links all their addresses. The victim’s wallet — unaware of the trap — has revealed its structure to the attacker.
Exchange and service attribution builds on the observation that large, regulated exchanges (Coinbase, Binance, Kraken) control identifiable clusters. Every deposit or withdrawal from a KYC exchange becomes an anchor. Analysts maintain databases of known exchange hot wallets and can tag any transaction that touches them. Government subpoenas then convert on-chain attribution into legal identity.
Even Monero is not perfectly opaque. Academic research (Möser et al., 2018; Yu et al., 2019) found that early Monero transactions used ring size 1 (no decoys), retroactively making those transactions traceable when the decoy pool was later analysed. Before RingCT, transaction amounts were visible. These are historical weaknesses now addressed by protocol upgrades, but they illustrate a general principle: privacy systems are only as strong as their weakest historical version, because adversaries can analyse the entire transaction history at any time.
Privacy in DeFi: Confidential Smart Contracts
06Monero and Zcash solve payment privacy for simple value transfers. But the DeFi ecosystem runs on smart contracts, and public Ethereum exposes not just transaction amounts and parties but the full logic of every trade: which tokens, at what prices, via which liquidity pools, at exactly which block. This transparency creates a class of exploits unknown in traditional finance: MEV (Maximal Extractable Value) and front-running, where validators or bots observe pending transactions in the mempool and insert their own trades to extract value from the original user.
A user swapping 100 ETH for USDC on Uniswap announces their trade to every node on the network before it executes. A searcher bot detecting this can immediately submit a front-running transaction with higher gas, buying ETH before the large order pushes up the price, then selling after the price impact — a sandwich attack that costs the original user typically 0.5–5% of their trade value. On Ethereum, MEV extraction exceeds $500 million per year by some estimates. The fundamental cause is that all pending transactions are public.
Several approaches address DeFi privacy. Commit-reveal schemes require users to post an opaque commitment in one block and reveal the transaction details in a later block. This limits front-running but introduces complexity and latency. Threshold encryption (used by Shutter Network) encrypts mempool transactions and requires a quorum of validators to jointly decrypt them only after inclusion — validators cannot selectively front-run what they cannot read. Secret Network uses a TEE (Trusted Execution Environment) running inside Intel SGX chips to execute smart contracts in encrypted memory, with inputs and outputs shielded from all observers including validators.
Regulatory Collision: OFAC, Delistings, and the Code-Is-Speech Debate
07Privacy technologies have attracted sustained regulatory attention because they conflict with the architecture of anti-money-laundering (AML) and counter-terrorism financing (CTF) frameworks. The Financial Action Task Force (FATF) Travel Rule requires financial institutions to collect and transmit originator and beneficiary information for transfers above $1,000. By design, Monero transactions cannot comply: there is no technical mechanism to attach identity information to an amount-hidden, sender-hidden transaction.
Privacy coins have faced exchange delistings as a compliance strategy. Bittrex, Kraken (for UK users), Gemini, and BitBay have all delisted Monero at various times, often citing pressure from banking partners or regulatory guidance. OKX delisted Monero, Dash, Zcash, and Horizen in 2023 for users in certain jurisdictions. For Monero in particular, this creates a liquidity concern: if trading is restricted to decentralised exchanges and peer-to-peer platforms, the on-ramp and off-ramp friction increases substantially.
The regulatory debate has deeper tensions. Privacy coins are used for illicit purposes, but so is cash — and cash lacks any traceability whatsoever. Chain analysis firm Chainalysis reported that illicit activity accounted for approximately 0.24% of crypto transaction volume in 2023. The vast majority of Tornado Cash users were not sanctioned entities. Regulation that prohibits privacy tools for all users to stop a minority of bad actors applies a principle that would, if extended consistently, prohibit end-to-end encryption in messaging.
Evaluation: Privacy by Design vs. Privacy by Compliance
08After studying the technical landscape, the engineer faces a design question that cannot be resolved by cryptography alone: how much privacy should a blockchain system provide, and for whom? The answer depends on threat model, jurisdiction, use case, and values — and it admits no universally correct answer. What the evidence does support is a clear taxonomy of design approaches.
Privacy by default (Monero approach) — All users receive maximum privacy automatically. Anonymity set is maximised. Regulatory compliance is structurally impossible in its current form. Best for: censorship-resistant value storage and transfer in high-stakes environments.
Privacy by choice (Zcash approach) — Users opt into shielded transactions. Regulatory compliance is possible via view keys. Anonymity set is smaller (only shielded pool users). Best for: institutional use cases requiring audit capability alongside privacy.
Privacy by ZK proof (Aztec/rollup approach) — Validity is proven without revealing data. Native to Layer 2 scaling. Potentially compatible with selective disclosure regulation. Best for: DeFi applications where MEV and front-running resistance are as important as financial privacy.
The trajectory of privacy technology is toward ZK-proof-based approaches because they offer a property that cryptographic obfuscation (ring signatures, mixing) does not: mathematical provability. A ring signature proves that someone in a set of 16 signed. A ZK-SNARK proves that a specific cryptographic statement is true with information-theoretic certainty. The verifier learns exactly what was intended to be revealed and nothing else — not a probabilistic approximation but a formal guarantee.
For the practising blockchain engineer, the key takeaways are practical. Pseudonymity is not privacy — any system that relies on address unlinkability without cryptographic enforcement will eventually be compromised by analytics. Mixing is weak without large anonymity sets and careful operational security. ZK proofs are production-ready — Zcash, StarkNet, and zkSync are live systems handling real economic value. And regulatory risk is the dominant practical constraint: a privacy-maximising design that cannot be deployed on any regulated exchange serves a narrow use case.
The broader message is that privacy in blockchain is not a binary state but a continuous spectrum controlled by protocol-level design choices. As a blockchain engineer or researcher, you will regularly encounter systems where the privacy properties are implicit rather than explicit, where the marketing says “private” but the architecture says “pseudonymous.” The frameworks in this lecture — anonymity sets, ZK proof properties, forensic heuristics, regulatory exposure — give you the vocabulary to evaluate those claims precisely and the technical toolkit to design systems with honest, quantifiable privacy guarantees.