9.1 Privacy on the Blockchain: Techniques and Protocols
The $1.2 Billion Privacy Problem
On August 8, 2022, the U.S. Treasury Department sanctioned Tornado Cash—a blockchain privacy protocol. The reason? It had been used to launder over $7 billion in cryptocurrency, including $455 million stolen by North Korean hackers.
But here's the paradox: Tornado Cash was also used by 48,000+ legitimate users for privacy-preserving transactions:
- Whistleblowers protecting their identity
- Businesses hiding commercial transactions from competitors
- Individuals avoiding targeted attacks
- Privacy advocates exercising digital rights
The incident crystallized blockchain's fundamental tension:
Blockchains are designed to be transparent:
Every transaction publicly visible
Every address balance trackable
Every interaction permanently recorded
Complete financial history accessible to anyone
But transparency creates serious problems:
Privacy invasion: Your salary, spending, savings all public
Security risk: Attackers can target wealthy addresses
Competitive harm: Businesses reveal strategies
Discrimination: Addresses can be blacklisted
Surveillance: Governments can track everyone
This isn't hypothetical. Real consequences:
Case 1: The $600M Hack Traced (August 2021)
Poly Network hack: $600M stolen
Hackers' addresses immediately known
Every transaction tracked in real-time
Assets frozen when moved to exchanges
Hacker returned funds (nowhere to cash out)
Case 2: $50M+ Stolen via Privacy (2020-2022)
North Korean hackers (Lazarus Group):
Steal crypto from exchanges
Use Tornado Cash to break transaction links
Cash out through anonymous services
Billions laundered successfully
The dilemma:
- Transparency enables accountability but destroys privacy
- Privacy enables crime but protects individuals
- No obvious middle ground
This lesson explores blockchain privacy—both the problem and attempted solutions:
What we'll cover:
- Why Bitcoin isn't anonymous (despite early claims)
- How transaction graph analysis deanonymizes users
- Privacy technologies: mixing, ring signatures, zk-SNARKs
- Tornado Cash: How it works and why it was sanctioned
- Monero, Zcash, and other privacy coins
- The fundamental trade-offs between privacy and transparency
- Whether blockchain privacy is even achievable
Current state (2024):
Bitcoin privacy: Poor (95%+ of addresses eventually linked)
Ethereum privacy: Worse (smart contract interactions reveal more)
Privacy coin usage: <1% of crypto volume
Privacy mixers: Mostly sanctioned or shut down
ZK technology: Promising but complex and expensive
Understanding blockchain privacy matters because:
- Privacy is a human right (UN Declaration, Article 12)
- Commercial viability requires privacy (businesses can't reveal all transactions)
- Security requires privacy (public wealth makes you a target)
- But so does accountability (preventing crime, money laundering, terrorism)
The question isn't whether we need privacy—we do. The question is: Can we have privacy on a transparent blockchain? And at what cost?
The Bitcoin Pseudonymity Myth
Why Bitcoin Isn't Anonymous
The original claim (2008):
Satoshi Nakamoto's Bitcoin whitepaper, Section 10:
"The traditional banking model achieves a level of privacy by limiting access to information... The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone... a new key pair should be used for each transaction to keep them from being linked to a common owner."
The reality:
Bitcoin provides pseudonymity, not anonymity:
Pseudonymity (Bitcoin):
- Addresses are pseudonyms (like "Alice123")
- Transactions between pseudonyms are public
- But pseudonyms can be linked to real identities
Anonymity (what people assumed):
- No link between transactions and identity
- Complete privacy
- Untraceable transactions
Why the distinction matters:
Pseudonymous: Like posting on Reddit with username "CryptoUser42"
- Posts are public
- Username identity unclear initially
- But IP logs, writing style, cross-references reveal identity
- Once linked, entire history exposed
Anonymous: Like Tor browser + anonymous email
- No persistent identifier
- No connection between actions
- Identity revelation doesn't expose history
The Bitcoin Transparency Problem
Every Bitcoin transaction is permanently public:
Transaction example (simplified):
Inputs:
1A1z... : 0.5 BTC
1B2y... : 0.3 BTC
Outputs:
1C3x... : 0.7 BTC (recipient)
1D4w... : 0.1 BTC (change)
Publicly visible:
✓ Input addresses
✓ Input amounts
✓ Output addresses
✓ Output amounts
✓ Transaction time
✓ Fee paid
✓ Complete history of every input (recursive)
What this reveals:
For each address, anyone can see:
- Total balance (unspent outputs)
- Complete transaction history
- All addresses interacted with
- Timing patterns
- Amount patterns
- Connected addresses (transaction graph)
Example analysis:
Address: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
(First Bitcoin address, Satoshi's)
Public information:
- Received: 68 transactions
- Total received: 72.48 BTC
- Current balance: 72.48 BTC
- First transaction: Jan 3, 2009 (Genesis block)
- Last transaction: Jan 2024 (recent donation)
- Connected to: 67 other addresses
- Likely owner: Satoshi Nakamoto (known)
All of this visible to ANYONE with internet access
Transaction Graph Analysis
Bitcoin creates a massive transaction graph:
Address A
↓ 2 BTC
Address B
↙ ↘
1 BTC 1 BTC
↓ ↓
Address C Address D
↓ ↓
0.5 BTC 0.8 BTC
↓ ↓
Address E Address F
↓ ↘ ↙ ↓
0.3 BTC
↓
Address G
Connections form massive directed acyclic graph (DAG)
Entire graph publicly queryable
Powerful analysis possible
Common analysis techniques:
1. Address clustering:
Heuristic 1: Common input ownership
If transaction has inputs from addresses A and B,
→ A and B likely controlled by same entity
(Need private keys for both to sign)
Example:
Transaction X:
Inputs: 1A1z..., 1B2y..., 1C3x...
Output: 1D4w... (3.5 BTC)
Conclusion: Addresses 1A1z, 1B2y, 1C3x same owner
Cluster them together
Repeat across entire blockchain
→ Reduces millions of addresses to thousands of entities
2. Change address detection:
Heuristic 2: One output is change
Most transactions have 2 outputs:
- Payment to recipient
- Change back to sender
Pattern:
Transaction from address A:
Input: A (1.0 BTC)
Output 1: B (0.3 BTC) ← Payment
Output 2: C (0.69 BTC) ← Change (probably)
If C is new address (first appearance):
→ C likely change address → owned by A's owner
If C then used as input with A:
→ Confirms C owned by A's owner
3. Temporal analysis:
Transactions from same entity often at similar times
- Same timezone
- Same day-of-week pattern
- Same hour-of-day pattern
Example:
Addresses A, B, C all transact:
- Monday-Friday, 9am-5pm Eastern
- Low activity weekends
→ Likely same U.S. business entity
4. Amount correlation:
Unusual amounts can be signatures:
- Round numbers → Retail purchases
- Specific decimals → Automated systems
- Matching patterns → Same entity
Example:
Multiple addresses sending 0.01234567 BTC
→ Likely same software wallet
→ Same user
5. Transaction fingerprinting:
Wallet software creates unique patterns:
- Fee calculation algorithms
- Output ordering
- Version fields
- Script types
Can identify wallet software:
→ "This is Electrum wallet"
→ "This is Bitcoin Core"
→ "This is Coinbase custody"
Real-World Deanonymization
Case Study: Silk Road (2013)
Silk Road was a darknet market (2011-2013) claiming Bitcoin anonymity. FBI traced anyway:
Silk Road Bitcoin address: 1DXxxx...
Total revenue: ~9.5M BTC over 2 years
FBI analysis:
1. Identified Silk Road's wallet clusters (common inputs)
2. Traced major deposits to exchanges
3. Exchanges provided KYC data (real identities)
4. Cross-referenced with other evidence
5. Connected transactions to Ross Ulbricht
Result: Operator arrested, convicted
Billions in Bitcoin seized
"Anonymous" marketplace traced
From "A Fistful of Bitcoins" paper (2013):
Researchers analyzed 344 Bitcoin services:
Results:
- 40% of services: Easily linked to real identities
- 20% of services: Linked with moderate effort
- 20% of services: Linked with significant effort
- 20% of services: Could not link (proper privacy practices)
Conclusion: 80% of Bitcoin services could be deanonymized
Methods used:
1. Public WHOIS records (domain registration)
2. Social media profiles
3. Email addresses in transactions (OP_RETURN data)
4. IP address logs
5. Transaction graph analysis
6. Timing correlations
Chainalysis and blockchain surveillance:
Modern blockchain analytics companies (Chainalysis, Elliptic, CipherTrace):
Services provided:
- Real-time transaction monitoring
- Address clustering (millions of addresses → entities)
- Entity identification (exchanges, darknet, hackers)
- Risk scoring (probability address is illicit)
- Sanctions screening (OFAC, other lists)
Customers:
- Law enforcement (FBI, Europol, etc.)
- Exchanges (compliance requirements)
- Banks (due diligence)
- Governments (tax enforcement)
Effectiveness:
- 95%+ of Bitcoin addresses can be clustered
- 60%+ can be linked to known entities
- Major hacks traced in real-time
- Criminal arrests increasing
Example:
2016 Bitfinex hack (120,000 BTC stolen)
Every movement tracked
2022: Arrests made, $3.6B recovered
Why Privacy Matters
Beyond criminal activity:
1. Personal security:
Problem: Public wealth is dangerous
Example:
You post Bitcoin address online (e.g., donation address)
Balance: 100 BTC (visible to everyone)
Current value: $4M
Result:
- Targeted for hacking, phishing, scams
- Physical security threat (kidnapping, extortion)
- Social engineering attacks on friends/family
Real incident (2020):
Youtuber posts Bitcoin address
Hackers discover $1M+ balance
SIM-swap attack → phone number stolen
Reset passwords, steal funds
2. Commercial privacy:
Problem: Business transactions public
Example:
Coffee shop accepts Bitcoin
All revenues public:
- Daily sales: $5,000 (50 transactions)
- Supplier payments: $2,000
- Employee salaries: $1,500
- Net profit: $1,500
Consequences:
- Competitors know exact business model
- Suppliers know profit margins (negotiate harder)
- Employees know each other's salaries
- Landlord knows how much you can pay
- Tax authority sees everything
Result: Uncompetitive, unsustainable
3. Financial privacy:
Problem: Personal finance is sensitive
Examples:
- Medical payments reveal health conditions
- Political donations reveal affiliation
- Online purchases reveal preferences
- Salary payments reveal income
- Loan applications reveal debt
With Bitcoin:
All visible permanently
To everyone
Forever
Imagine: Bank account transactions published on public website
No one would accept this
Yet blockchain does exactly this
4. Freedom and human rights:
Problem: Surveillance enables oppression
Use cases requiring privacy:
- Journalists receiving sensitive information
- Whistleblowers reporting corruption
- Dissidents in authoritarian regimes
- Activists organizing protests
- Humanitarian aid in conflict zones
Without privacy:
- Sources compromised
- Whistleblowers prosecuted
- Dissidents arrested
- Activists targeted
- Aid workers endangered
UN Declaration of Human Rights, Article 12:
"No one shall be subjected to arbitrary interference with his privacy..."
Ethereum's Privacy Problem is Worse
Why Ethereum privacy is harder:
Bitcoin:
- Simple transactions (send from A to B)
- Limited metadata
- Mostly payment use case
Ethereum:
- Smart contract interactions (complex)
- Function calls reveal intent
- More metadata (method names, parameters)
- Multiple use cases (DeFi, NFTs, tokens)
Result: More information leakage
Example: DeFi privacy breach:
User interacts with Aave:
0xUser... → Aave.deposit(ETH, amount=10)
→ Aave.borrow(USDC, amount=15000)
Publicly visible:
- User address: 0xUser...
- Action: Deposited 10 ETH (~$20k)
- Action: Borrowed $15k USDC
- Implied: User needs liquidity but bullish on ETH
- Health factor: ~1.33 (calculated from public data)
If ETH drops 20%:
- Anyone can see user is near liquidation
- Front-run with liquidation attempt
- Extract liquidation bonus
- User loses money publicly
Token transfers even worse:
ERC-20 token: All transfers public
USDC transfer: 0xAlice... → 0xBob... : 50,000 USDC
Additional leakage:
- If Bob is exchange: Alice cashing out
- If Bob is merchant: Alice bought something
- If Bob is Bob (known): Alice paying specific person
- If multiple payments: Business relationship
Cross-reference:
- Alice's address on multiple chains
- Alice's other token holdings
- Alice's DeFi positions
- Alice's NFT purchases
Result: Complete financial profile
Available to anyone
NFT purchases reveal even more:
Alice buys CryptoPunk #1234 for 100 ETH
Reveals:
- Wealth: Has 100 ETH
- Taste: Likes CryptoPunks
- Social: Part of NFT community
- Timing: Buying at peak/trough
- Future intent: Likely to buy more NFTs
If CryptoPunk #1234 is specific:
- Trait: "Zombie with Beanie"
- Personal: Might relate to real identity
- Cross-reference: Other zombie owners
- Social graph: Who transferred to Alice
Combined with:
- ENS domain (alice.eth → reveals name)
- Twitter (links address in bio)
- Discord (same address for verification)
Result: Pseudonymity broken
Real identity revealed
Privacy Technologies: Mixing and CoinJoin
The Mixing Concept
Basic idea: Break transaction links by pooling
Without mixing:
Alice → 1 BTC → Bob (direct link)
With mixing:
Alice → 1 BTC → Mixer Pool → 1 BTC → Bob
↓
(many users)
Observer sees:
- Alice sent 1 BTC to mixer
- Bob received 1 BTC from mixer
- But which of many users sent to Bob?
The anonymity set:
Anonymity Set = Number of possible senders
Example:
10 users deposit 1 BTC each
10 users withdraw 1 BTC each
For any withdrawal:
Could have come from any of 10 deposits
Anonymity set: 10
Probability of correct guess: 1/10 = 10%
Larger anonymity set = Better privacy
CoinJoin: Trustless Mixing
Problem with centralized mixers:
Users must trust mixer:
- Not to steal funds
- Not to log transactions
- Not to cooperate with authorities
- Not to be hacked
History: Many mixers stole funds or were compromised
CoinJoin solution (2013):
Proposed by Greg Maxwell, trustless mixing:
Multiple users create single transaction together:
Inputs (from different users):
Alice: 1 BTC from 1A1z...
Bob: 1 BTC from 1B2y...
Carol: 1 BTC from 1C3x...
Outputs (all same amount):
1X... : 1 BTC (one of Alice/Bob/Carol)
1Y... : 1 BTC (one of Alice/Bob/Carol)
1Z... : 1 BTC (one of Alice/Bob/Carol)
Result:
- Single transaction with multiple parties
- Unclear which input funded which output
- No need to trust anyone (atomic)
Why it's trustless:
Transaction only valid if ALL participants sign
If anyone tries to cheat, transaction fails
No funds lost (transaction doesn't go through)
Process:
1. Participants coordinate (off-chain)
2. Build transaction together
3. Everyone signs their input
4. If all sign: Broadcast
5. If anyone doesn't sign: Abort, try again
No trusted third party needed
Wasabi Wallet example:
Popular CoinJoin implementation:
Coordinator: Wasabi server (doesn't custody funds)
Minimum: 0.01 BTC
Fee: 0.3% coordinator fee
Rounds: Automated, every ~hour
Anonymity set: 50-150 per round
Process:
1. Users register inputs
2. Coordinator creates transaction template
3. Users verify and sign
4. Coordinator broadcasts
Users never reveal which output is theirs to coordinator
Zero-knowledge proof confirms they contributed
Limitations of Mixing
1. Timing correlation:
If Alice mixes 1 BTC at time T
And Bob withdraws 1 BTC at time T+5min
→ Likely Alice's funds went to Bob
Mitigation:
- Random delays
- Multiple rounds
- Large anonymity sets
2. Amount correlation:
If Alice mixes 1.23456789 BTC (unusual amount)
And Bob withdraws 1.23456789 BTC
→ Definitely Alice's funds
Mitigation:
- Fixed denominations (0.01, 0.1, 1 BTC)
- No custom amounts
3. Change addresses:
Alice mixes 1.5 BTC:
- Input: 1.5 BTC from 1A...
- Output: 1.0 BTC mixed
- Change: 0.5 BTC to 1B...
Change address links to original:
1A... and 1B... connected (same owner)
If change is later mixed with 1.0 BTC output:
→ Links unmixed change to mixed output
→ Privacy broken
Mitigation:
- Don't mix change with mixed outputs
- Multiple mixing rounds
- Careful UTXO management
4. Sybil attacks:
Attacker controls majority of participants in mix:
Example:
100 participants, attacker controls 90
Real users: Alice, Bob, Carol, ... (10 total)
Attacker: 90 addresses
Attacker sees:
Alice deposits to address X
Only 10 possible withdrawals are real users
→ Anonymity set reduced to 10, not 100
Worse: Attacker might control 99/100
→ Knows exactly which output is Alice's (process of elimination)
Mitigation:
- Reputation systems (hard)
- Proof of work per participant (expensive)
- Identity requirements (defeats purpose)
5. Blockchain heuristics still work:
Even after mixing, patterns remain:
- Wallet fingerprinting
- Temporal patterns
- Transaction graph analysis (broader)
Studies show:
- 20-30% of mixed coins can be re-linked
- Especially if only single mixing round
- Need multiple rounds + careful management
Regulatory Response
Legal status of mixing:
United States (2024):
- Centralized mixers: Considered money transmitters
- Require MSB license, FinCEN registration
- Most are illegal (operating without license)
- Several operators arrested
Tornado Cash (2022):
- Sanctioned by OFAC (Office of Foreign Assets Control)
- Using it became illegal for U.S. persons
- Developer arrested in Netherlands
Other countries:
- EU: Similar restrictions emerging
- China: All crypto transactions illegal
- Offshore: More permissive, but risky
The regulatory argument:
Legitimate uses exist (privacy)
But high percentage illicit:
Chainalysis data (2022):
Tornado Cash usage:
- $7.6B total volume
- $1.5B from illicit sources (20%)
- Major hacks, scams, stolen funds
Comparison:
Traditional finance illicit rate: 2-5%
Tornado Cash: 20%+
Regulators: "Too high to ignore"
Privacy advocates: "Still 80% legitimate use!"
The chilling effect:
After Tornado Cash sanctions:
- Other mixers shut down preemptively
- Developers afraid to work on privacy tools
- Users afraid to mix (even legitimately)
- Privacy research chilled
Result: Less privacy available
Centralizing control
Surveillance increases
Advanced Privacy: Ring Signatures and Monero
The Ring Signature Concept
Problem with mixing: Still shows transaction occurred, just obscures parties
Ring signature solution: Hide sender among a group
Traditional digital signature:
Alice signs message with private key
Anyone can verify: "Alice signed this"
Ring signature:
One of {Alice, Bob, Carol, ... , Zeke} signed message
Anyone can verify: "Someone in this group signed"
But impossible to tell who
Properties:
- Signer ambiguous (could be any group member)
- No setup needed (can include anyone's public key)
- Unconditional privacy (even quantum computers can't break)
Mathematical intuition (simplified):
Alice wants to sign message m
Picks group: {Alice, Bob, Carol}
Alice knows:
- Her private key: sk_A
- Bob's public key: pk_B (from blockchain)
- Carol's public key: pk_C (from blockchain)
Signing process:
1. Generate random values: r_B, r_C
2. Compute: c_B = Hash(m, pk_B, r_B)
c_C = Hash(m, pk_C, r_C)
3. Solve for r_A such that:
c_A = Hash(m, pk_A, r_A)
And: c_A ⊕ c_B ⊕ c_C = 0 (XOR to zero)
Signature: {c_A, c_B, c_C, r_A, r_B, r_C}
Verification:
- Check all hash equations valid
- Check XOR condition
- Don't know which party actually signed
Monero: Anonymous by Default
Monero architecture:
1. Ring Signatures (hide sender):
Every transaction references 10-16 decoy outputs
Looks like it could be spending any of them
Real output hidden among decoys
Transaction example:
Inputs (all appear equally likely):
Output 12345: 1 XMR (decoy)
Output 23456: 1 XMR (decoy)
Output 34567: 1 XMR (REAL, but hidden)
Output 45678: 1 XMR (decoy)
... (11 more decoys)
Observer cannot tell which is real spend
Anonymity set: 16 per transaction
2. Stealth Addresses (hide receiver):
Instead of reusing addresses:
- Recipient publishes "stealth address" (public)
- For each payment, sender generates new one-time address
- Only recipient can detect payment (scanning blockchain)
- Addresses never reused on blockchain
Example:
Alice's stealth address: 4A1z...
Bob sends 1 XMR to Alice
On blockchain:
Output: 1 XMR to 1X2Y3Z... (one-time address)
Only Alice can:
- Scan blockchain for outputs to her
- Compute matching private key
- Spend the funds
Observer sees:
- All addresses used once
- No address reuse
- Cannot tell who received funds
3. RingCT (hide amounts):
Transaction amounts encrypted
Only sender and receiver know amount
Transaction appears as:
Input: ??? XMR (encrypted)
Output: ??? XMR (encrypted)
Fee: 0.001 XMR (public, for miners)
Verification:
- Cryptographic proofs confirm:
* Inputs = Outputs + Fee (no money created)
* Amounts are positive (no negative amounts)
* No overflow errors
- But amounts remain hidden
Technology: Pedersen Commitments + Range Proofs
Combined effect:
Monero transaction reveals:
✗ Who sent (hidden among 16 others)
✗ Who received (one-time address)
✗ How much (encrypted)
✓ That transaction occurred (timing, fees)
Much stronger privacy than Bitcoin
Monero Privacy Guarantees
Anonymity set size:
Bitcoin with mixing:
Anonymity set: 50-150 (per mix round)
Requires active participation
Costs fees
Optional (most don't use)
Monero:
Anonymity set: 16 per transaction (mandatory)
All transactions automatically private
No extra fees
Default behavior
After N transactions:
Bitcoin: Some mixed, some not (fragmented privacy)
Monero: All private (uniform privacy)
Network effect:
Bitcoin: Privacy stands out
Monero: Privacy is normal
Limitations:
1. Decoy selection:
Decoys must be realistic to be effective
Problem: If recent outputs more likely to be spent
And decoys are selected randomly from all time
→ Old decoys are suspicious
→ Recent outputs more likely real
Mitigations:
- Gamma distribution for selection (weight recent)
- Increasing ring size (16 → possibly higher)
- Ongoing research
2. Chain analysis still possible:
Studies show:
- 45% of pre-RingCT transactions traceable (2014-2016)
- With RingCT (2017+): <2% traceable
- But edge cases remain:
* Miner coinbase outputs (no decoys possible)
* Exchange deposits/withdrawals (timing/amounts)
* Network-level traffic analysis (IP addresses)
3. Scalability concerns:
Ring signatures = larger transactions
Monero transaction: ~2 KB
Bitcoin transaction: ~250 bytes
Ratio: 8x larger
Blockchain size grows faster
More storage needed
More bandwidth needed
Monero blockchain (2024): ~180 GB
Bitcoin blockchain (2024): ~600 GB
But: Monero has much less usage
At equal usage, would be 5x larger
Zcash: Zero-Knowledge Proofs
Different approach: zk-SNARKs
zk-SNARK = Zero-Knowledge Succinct Non-Interactive Argument of Knowledge
Allows proving statements without revealing information:
Statement: "I know x such that Hash(x) = y"
Proof: (cryptographic proof, small size)
Verifier can check:
✓ Proof is valid
✓ Statement is true
✗ Cannot learn x
✗ Cannot learn anything except statement truth
Size: ~200 bytes (constant, regardless of statement complexity)
Verification: Milliseconds
Zcash architecture:
Two types of addresses:
1. Transparent addresses (t-addresses):
Like Bitcoin: Public transactions
2. Shielded addresses (z-addresses):
Private transactions using zk-SNARKs
Transaction types:
- t→t: Fully public (like Bitcoin)
- t→z: Public input, private output (shielding)
- z→z: Fully private (best privacy)
- z→t: Private input, public output (de-shielding)
How z→z transactions work:
Alice (z-address) sends 10 ZEC to Bob (z-address)
On blockchain:
Input: (encrypted)
Output: (encrypted)
Proof: 0x1a2b3c... (zk-SNARK, 200 bytes)
Blockchain records:
✗ Who sent (private)
✗ Who received (private)
✗ Amount (private)
✓ Proof of validity (public)
Proof confirms:
- Alice owns input coins (without revealing which)
- Alice sent to valid recipient (without revealing who)
- Amount in = Amount out (without revealing amounts)
- No double-spending
- All rules followed
Verification: Anyone can verify proof
Information revealed: Zero (hence "zero-knowledge")
Advantages over Monero:
1. Stronger cryptographic guarantees:
Monero: Probabilistic (decoy-based)
Zcash: Computational (math-based)
2. Smaller proofs:
Monero ring signature: ~2 KB
Zcash zk-SNARK: ~200 bytes
3. Potential for complex policies:
Can prove arbitrary statements
"I am over 18" without revealing age
"I have >$1000 balance" without revealing amount
Disadvantages:
1. Trusted setup required:
Generated "toxic waste" during setup
If anyone has the waste, can create fake coins
Requires ceremony with multiple parties
Trust assumption that one party was honest
2. Computationally intensive:
Generating proof: 30-60 seconds
High CPU and memory requirements
Difficult on mobile devices
3. Low adoption:
<3% of Zcash in shielded addresses (2024)
Most users use t-addresses (no privacy)
Network effect: Privacy rare, stands out
4. Newer, complex math:
Cryptographic assumptions less battle-tested
Potential for unknown vulnerabilities
Academic cryptography vs. deployed systems
Comparison: Monero vs Zcash vs Bitcoin Mixing
Property Bitcoin+Mix Monero Zcash (z→z)
──────────────────────────────────────────────────────────────
Privacy default No Yes No
Adoption 5-10% 100% <3%
Anonymity set 50-150 16 "All"
Sender hidden Sometimes Yes Yes
Receiver hidden Sometimes Yes Yes
Amount hidden No Yes Yes
Transaction size Normal 8x larger Normal
Proof generation N/A Fast Slow (30s)
Trusted setup No No Yes
Regulatory status Restricted Delisted Available
Usage (2024):
Bitcoin volume: $20B+/day
Monero volume: $50M/day (0.25%)
Zcash volume: $20M/day (0.1%)
The network effect problem:
Privacy requires usage:
Small anonymity set:
"1 in 100 users uses privacy"
→ Privacy users stand out
→ Suspicious
→ Targeted for scrutiny
Large anonymity set:
"Everyone uses privacy"
→ Privacy is normal
→ No stigma
→ Better for everyone
Current state:
Bitcoin: Privacy rare, complex, expensive
Monero: Privacy universal, default
Zcash: Privacy available but rarely used
Outcome: Monero has best practical privacy
Tornado Cash: The Rise and Fall
How Tornado Cash Works
Design: Non-custodial privacy mixer using zk-SNARKs
Architecture:
Smart contract on Ethereum
Pools:
- 0.1 ETH pool
- 1 ETH pool
- 10 ETH pool
- 100 ETH pool
- (Also tokens: DAI, USDC, etc.)
No custodian, all trustless
Uses zero-knowledge proofs
Deposit phase:
1. User generates secret (random 256-bit number)
2. Compute commitment: hash(secret)
3. Send deposit transaction:
- Send 1 ETH to Tornado contract
- Include commitment in transaction
- Commitment added to Merkle tree
On-chain:
Address 0xAlice... → 1 ETH → Tornado Contract
Commitment: 0x1a2b3c... (added to tree)
No connection between address and secret
Merkle tree accumulator:
Tornado contract maintains Merkle tree of all deposits:
Root
├─ Hash12
│ ├─ Hash1
│ │ ├─ Commitment A
│ │ └─ Commitment B
│ └─ Hash2
│ ├─ Commitment C
│ └─ Commitment D
└─ Hash34
└─ ...
Every deposit adds new leaf (commitment)
Root hash updated each deposit
Accumulates all deposits without revealing links
Withdrawal phase:
User wants to withdraw to new address:
1. User knows: secret, Merkle proof
2. User generates zk-SNARK proof proving:
"I know secret such that:
- Hash(secret) is in Merkle tree
- I have not withdrawn before (nullifier check)"
3. Send withdrawal transaction:
From: Any address (can be new, not linked)
To: Tornado contract
Function: withdraw(proof, nullifier, recipient)
4. Contract verifies:
- Proof is valid (zk-SNARK verification)
- Nullifier not used before (prevent double-withdraw)
- Sends 1 ETH to recipient address
On-chain:
Tornado Contract → 1 ETH → 0xBob... (new address)
No link between 0xAlice (deposit) and 0xBob (withdrawal)
The zk-SNARK proof:
Public inputs:
- Merkle root (current state)
- Nullifier (prevents double-spending)
- Recipient address
Private inputs:
- Secret
- Merkle proof (path in tree)
Proof confirms:
"I know a secret that:
1. Hash(secret) is in the tree (valid deposit)
2. Nullifier = Hash(secret, 1) (unique per withdrawal)
3. But I don't reveal the secret"
Verifier confirms:
✓ Mathematical proof is valid
✗ Cannot learn which deposit was spent
✗ Cannot link deposit to withdrawal
Anonymity set: All deposits in pool
For 1 ETH pool: 10,000+ deposits
→ 1 in 10,000+ chance of guessing correctly
Why it's trustless:
Smart contract:
- Cannot censor deposits
- Cannot censor withdrawals
- Cannot link deposits to withdrawals
- Cannot steal funds (no admin keys)
Cryptography:
- zk-SNARK ensures only valid withdrawals
- Merkle tree ensures all deposits accounted
- Nullifier prevents double-spending
No trust required:
- No operator with special powers
- All code on-chain, publicly auditable
- Mathematics guarantees privacy
Practical Usage Example
Scenario: Alice wants privacy
Current situation:
Alice has 10 ETH in address 0xAlice...
Address well-known (used for airdrops, etc.)
Wants fresh address with no links
Process:
1. Generate secret in browser:
secret = 0x7f3a9b2c...
commitment = hash(secret)
2. Deposit from 0xAlice:
Send 1 ETH to Tornado 1 ETH pool
Include commitment
Repeat 10 times (for all 10 ETH)
3. Wait (recommended: hours to days)
More deposits from other users
Larger anonymity set
Harder to correlate timing
4. Withdraw to new address 0xBob:
Generate proof for each secret
Withdraw 1 ETH each time
Spacing: Random delays (avoid timing correlation)
Result:
0xAlice has 0 ETH (all deposited)
0xBob has 10 ETH (all withdrawn)
No on-chain link between them
Observers see:
- 0xAlice deposited 10 ETH
- 0xBob withdrew 10 ETH
- But 10,000 other deposits in between
- Could be any of 10,000+ combinations
Privacy guarantees:
Anonymity set:
1 ETH pool (example): 10,000 deposits
Alice's anonymity set: 1 in 10,000
Breaking privacy requires:
- Timing analysis (deposit/withdrawal correlation)
- Amount analysis (unique amounts stand out)
- Graph analysis (connected addresses)
Best practices:
- Wait >24 hours between deposit/withdrawal
- Don't withdraw full amount immediately
- Split across multiple transactions
- Use relayer (third party submits withdrawal)
- Fund relayer fee from different source
Relayers: Solving the "First Transaction" Problem
Problem:
Withdrawing to new address requires:
- Gas fee to call withdraw function
- But new address has no ETH
- Funding address reveals link
Example:
0xAlice deposits 1 ETH to Tornado
Wants to withdraw to 0xBob (new, empty)
But: 0xBob needs 0.01 ETH for gas
If 0xAlice sends 0.01 ETH to 0xBob:
→ Link revealed! Privacy broken.
Solution: Relayers
Relayer = third-party service
- Submits withdrawal transaction on user's behalf
- Pays gas fee
- User compensates relayer from withdrawn amount
Process:
1. User generates proof (client-side)
2. User sends proof to relayer (off-chain)
3. Relayer submits transaction
4. Contract sends:
- 0.99 ETH to user (0xBob)
- 0.01 ETH to relayer (fee)
Result:
- 0xBob receives ETH without needing prior balance
- No link to funding source
- Relayer is intermediary (can't steal, only submit)
Relayer concerns:
Centralization:
- Relayers are trusted to submit (but can't steal)
- Could log IP addresses (deanonymize users)
- Could censor transactions
Mitigations:
- Multiple relayer options
- Anyone can run relayer
- Can submit directly (if have gas)
Privacy:
- Use VPN/Tor when contacting relayer
- Relayer doesn't learn secret or deposit
- Worst case: Relayer learns withdrawal address
Tornado Cash Nova: Shielded Pools
2022 upgrade: Arbitrary amounts
Problem with fixed denominations:
Pools: 0.1, 1, 10, 100 ETH
Inflexible:
- Want to mix 15 ETH?
Need: 10 ETH pool + 1 ETH pool × 5
Result: Multiple transactions, more fees
- Want to mix 1.5 ETH?
Need: 1 ETH pool + 0.1 ETH pool × 5
Result: Leaves 0 ETH unmixed
Tornado Cash Nova solution:
Shielded pool with arbitrary amounts:
- Deposit any amount (e.g., 15.7 ETH)
- Withdraw any amount (e.g., 3.2 ETH)
- Internal accounting via zk-SNARKs
- Balances encrypted
Benefits:
- More flexible
- Single transaction for any amount
- Larger anonymity set (all amounts together)
How it works:
Internal balance (private):
- Each user has shielded balance
- Only user knows balance (encrypted)
Deposit:
Address 0xAlice → 15.7 ETH → Nova Contract
Internal: Alice shielded balance = 15.7 ETH
Withdrawal:
Generate proof: "I have 3.2 ETH in shielded balance"
Contract: Verify proof, send 3.2 ETH to recipient
Internal: Alice shielded balance = 12.5 ETH
Multiple withdrawals:
Can withdraw 12.5 ETH later (in any amounts)
No connection between withdrawals
Why Tornado Cash Was Sanctioned
The illicit usage data:
Chainalysis report (2022):
Total Tornado Cash volume: $7.6B (lifetime)
Identified illicit funds: $1.54B (20%)
Breakdown of illicit funds:
$455M: Lazarus Group (North Korean hackers)
$272M: Other hacks (various)
$201M: Darknet markets
$612M: Scams and fraud
Major incidents:
2021: Poly Network hack ($600M) → Laundered via Tornado
2022: Ronin Network hack ($625M) → Laundered via Tornado
2020-22: Numerous DeFi hacks → Tornado used frequently
The sanctions (August 2022):
U.S. Treasury OFAC (Office of Foreign Assets Control):
- Added Tornado Cash to SDN list (Specially Designated Nationals)
- Made it illegal for U.S. persons to interact with Tornado
- Blocked 44 USDC/USDT addresses connected to Tornado
Consequences:
- Using Tornado Cash: Federal crime (up to 20 years prison)
- Applies to all U.S. citizens, residents, companies
- Even previous legitimate uses became retroactively scrutinized
Justification:
"Tornado Cash has been used to launder more than $7 billion
worth of virtual currency since its creation in 2019."
Developer arrest (August 2022):
Alexey Pertsev (co-founder):
- Arrested in Netherlands
- Charged: Money laundering facilitation
- Bail: Denied (flight risk)
- Trial: Ongoing (2023-2024)
Charges:
- Facilitated money laundering through Tornado Cash
- Conspiracy with hackers
- Failure to implement AML controls
Defense:
- Published open-source code (speech)
- No control over usage (decentralized)
- Privacy is a right
- Comparable to arresting Tor developers
Crypto community response:
- Outrage: "Code is speech"
- Concern: Chilling effect on privacy development
- Legal defense fund raised: $600k+
Controversy:
Privacy advocates:
- Tornado Cash is tool, not service
- Like prosecuting VPN developer
- 80% of usage was legitimate
- Privacy is human right
Law enforcement:
- 20% illicit is too high (vs 2% in trad finance)
- Enabled North Korean nuclear program funding
- No AML/KYC compliance
- Knowingly facilitated crime
Technical community:
- Code is published, open-source
- No one "operates" it (smart contract)
- Impossible to shut down (on blockchain)
- Setting dangerous precedent
Result: Ongoing debate
Legal challenges filed
Other privacy tools afraid
Post-Sanction Landscape
Immediate effects:
August 2022:
- Tornado Cash usage drops 90%
- Other mixers shut down preemptively
- Privacy tool development slows
Circle (USDC issuer):
- Blacklisted 44 addresses
- Froze $75k USDC in Tornado contract
- Set precedent for censorship
Developer exodus:
- Privacy researchers leave U.S.
- Projects relocate offshore
- Open-source contributions decline
Alternatives attempted:
2023-2024: New privacy tools
- Railway (privacy DEX) - low adoption
- Umbra (stealth addresses) - niche use
- Aztec (privacy layer) - still in development
- None reach Tornado's scale
Fork attempts:
- Tornado.cash on other chains
- Often scams or honeypots
- Lack security audits
- Low trust, low adoption
The privacy vacuum:
Current state:
- Tornado Cash still on-chain (can't remove smart contracts)
- But illegal for U.S. persons to use
- Some international users still use (risk)
- Most avoided (legal risk, tainted coins)
Result:
- Less privacy available
- Centralized exchanges dominate (KYC required)
- Chain analysis companies thrive
- Privacy becomes luxury/risk
Unintended consequence:
- Legitimate users lost privacy
- Criminals still find ways (foreign exchanges, mixers)
- Net effect: Punished privacy advocates more than criminals
Confidential Transactions and MimbleWimble
Confidential Transactions (CT)
Problem: Transaction amounts leak information
Public amounts enable:
- Identifying change outputs
- Tracking transaction flows
- Analyzing balances
- Inferring business relationships
Example:
Transaction: 1.234567 BTC → 0.5 BTC + 0.734567 BTC
Clearly: 0.734567 BTC is change (unusual amount)
Solution: Pedersen Commitments
Mathematical foundation:
Public parameters: G, H (elliptic curve points, discrete log unknown)
Commit to amount v:
C = v×G + r×H
Where:
v = amount (secret)
r = random blinding factor (secret)
C = commitment (public)
Properties:
1. Hiding: Cannot determine v from C
2. Binding: Cannot find v' ≠ v with same C
3. Homomorphic: C(v1) + C(v2) = C(v1 + v2)
Why homomorphic property matters:
Transaction with inputs and outputs:
Inputs: C1 = v1×G + r1×H
C2 = v2×G + r2×H
Outputs: C3 = v3×G + r3×H
C4 = v4×G + r4×H
Verification:
C1 + C2 = C3 + C4 ?
Expands to:
(v1 + v2)×G + (r1 + r2)×H = (v3 + v4)×G + (r3 + r4)×H
If v1 + v2 = v3 + v4 (no money created):
And r1 + r2 = r3 + r4 (sender adjusts blinding factors)
Then equation holds!
Verifier confirms:
✓ Inputs = Outputs (no money created/destroyed)
✗ Cannot see amounts
Range proofs:
Problem: Negative amounts could break system
Example:
Input: 5 BTC
Output 1: 10 BTC
Output 2: -5 BTC (negative!)
Commitment math still works:
5 = 10 + (-5) ✓
But: Negative amounts should be invalid
Solution: Range proof
Prove: "Amount is between 0 and 2^64 - 1"
Without revealing amount
Technology: Bulletproofs (efficient range proofs)
Size: ~700 bytes per output
Verification: ~5ms per output
Elements Confidential Transactions
Liquid Network implementation:
Sidechain of Bitcoin with CT enabled:
Transaction example (Liquid):
Inputs:
Amount: (encrypted) C1
Asset: (encrypted) A1
Outputs:
Amount: (encrypted) C2
Asset: (encrypted) A2
Amount: (encrypted) C3
Asset: (encrypted) A3
Proofs:
Range proof: C2 in [0, 2^64]
Range proof: C3 in [0, 2^64]
Equation: C1 = C2 + C3 (verified)
Observer sees:
✗ Amounts (encrypted)
✗ Asset types (multiple assets on Liquid)
✓ Transaction occurred
✓ Math is valid
Privacy: High
Verifiability: Full (cryptographic proofs)
Advantages:
+ Amounts hidden (better privacy)
+ Still fully verifiable (no trust needed)
+ Assets can be multiple types (not just BTC)
+ Efficient verification (~1ms per commitment)
Disadvantages:
- Larger transactions (~5x Bitcoin)
- More complex cryptography (newer)
- Sidechain (not directly Bitcoin)
- Lower adoption (niche use)
MimbleWimble: Full Privacy Protocol
Design by Tom Elvis Jedusor (likely pseudonym, "Voldemort" in French)
Radical approach: No addresses, no scripts, just commitments
Traditional blockchain:
- List of transactions
- Each transaction: inputs, outputs, scripts, signatures
- Full history preserved
MimbleWimble blockchain:
- Set of unspent outputs (UTXOs)
- Commitments only (no addresses)
- Transaction graph prunable
- Extremely compact
Key innovations:
1. No addresses:
Instead of sending to address:
- Sender and receiver interact
- Create shared transaction
- Only commitments on-chain
Example:
Alice sends to Bob:
1. Alice: Creates commitment C1 (blinded amount)
2. Bob: Provides commitment C2 (change)
3. Together: Create transaction
Input: Alice's UTXO
Output: C1 (to Bob), C2 (Alice's change)
4. Sign: Both sign (interactive)
No address visible on-chain
Only commitments
2. Transaction cut-through:
Normal blockchain:
Alice → Bob → Carol → Dave
Three transactions forever
MimbleWimble:
Intermediate steps can be removed
Final: Alice → Dave
Bob and Carol's outputs pruned
Result: Blockchain stays small
Old transactions aggregated
Only current UTXO set matters
3. Aggregation:
Multiple transactions in block can merge:
Separate:
Tx1: A→B (with signatures, proofs)
Tx2: C→D (with signatures, proofs)
Aggregated:
Combined: A+C → B+D (single signature, combined proofs)
Benefits:
- Smaller blocks
- More privacy (less structure visible)
- Better scalability
Grin and Beam: MimbleWimble implementations
Grin (launched 2019):
- Pure MimbleWimble
- No premine, fair launch
- Very compact blockchain (~2 GB after 5 years)
- Interactive transactions (sender-receiver coordination)
- Privacy by default
Beam (launched 2019):
- MimbleWimble + improvements
- Opt-in auditability (for compliance)
- Better UX (address-like "SBBS" addresses)
- Desktop wallet, mobile apps
Adoption:
- Low (<$1M daily volume)
- Niche community
- Not widely supported on exchanges
- Technical complexity limits adoption
Challenges:
1. Interactive transactions:
- Sender and receiver must be online simultaneously
- Or use intermediary servers (reduces privacy/decentralization)
- Poor UX for casual users
2. Limited functionality:
- No scripts (no smart contracts)
- No multi-sig (without extensions)
- Basic payment only
3. Network effects:
- Low liquidity
- Few exchanges list
- Hard to acquire/sell
4. Regulatory concern:
- Strong privacy = regulatory scrutiny
- Delisted from major exchanges
- Similar issues as Monero
The Privacy vs Transparency Trade-off
Why We Need Both
The case for transparency:
Positive aspects:
1. Auditability: Can verify monetary supply
2. Accountability: Reduces corruption
3. Compliance: Enables legal/tax enforcement
4. Security: Detect hacks, exploits quickly
5. Research: Analyze network health
Examples:
- DeFi protocol audits (detect bugs via public data)
- Tax compliance (government can verify)
- Fraud detection (analytics companies spot patterns)
- Academic research (understand crypto usage)
The case for privacy:
Positive aspects:
1. Human right: Financial privacy is fundamental
2. Security: Don't advertise wealth
3. Commercial: Business confidentiality
4. Freedom: Avoid censorship/discrimination
5. Fungibility: All coins should be equal
Examples:
- Dissidents in authoritarian regimes
- Businesses protecting trade secrets
- Individuals avoiding targeted attacks
- Journalists protecting sources
- Avoiding address blacklisting
The Fundamental Tension
Transparency vs Privacy is zero-sum:
More transparency → Less privacy
More privacy → Less transparency
Can't maximize both simultaneously
Design space spectrum:
Full Transparency Selective Full Privacy
(Bitcoin) (Compliance-friendly) (Monero)
↓ ↓ ↓
┌─────────────────────────────────────────────────────┐
│ Public │ Viewing │ Selective │ Encrypted │ Hidden │
│ amounts │ keys │ reveal │ txs │ always │
└─────────────────────────────────────────────────────┘
↑ ↑ ↑
Today Ideal? Censored
(most) (balance) (delisted)
Different systems make different choices:
Bitcoin:
- Choice: Maximum transparency
- Rationale: Auditability, simplicity
- Cost: No privacy (must add layers)
Zcash:
- Choice: Optional privacy
- Rationale: Flexibility (users choose)
- Cost: Transparent by default (only 3% use privacy)
Monero:
- Choice: Mandatory privacy
- Rationale: Network effect, fungibility
- Cost: Regulatory issues, delisting
Ethereum:
- Choice: Transparent (enables DeFi)
- Rationale: Composability requires visibility
- Cost: Privacy very difficult
Selective Disclosure
Idea: Privacy by default, disclosure when needed
Viewing keys:
Zcash viewing keys:
- Normal key: Can spend
- Viewing key: Can see transactions (but not spend)
Use case:
- Business: Privacy from competitors
- But: Auditor can verify (given viewing key)
- Regulators: Can request viewing key (compliance)
Example:
Company uses Zcash shielded address
- Public: Cannot see transactions
- Auditor: Given viewing key → sees all
- Selective disclosure to trusted parties
Proof of compliance:
Zero-knowledge proof of regulatory compliance:
"I prove that my transaction:
- Came from legitimate source (not sanctions list)
- Is under reporting threshold ($10k)
- Is not going to sanctioned address"
Without revealing:
- Exact amount
- Exact source
- Exact destination
Technology:
- zk-SNARKs enable this
- Not yet widely implemented
- Research ongoing
The ideal (theoretical):
Privacy by default:
- All transactions private
- Amounts encrypted
- Parties hidden
But with compliance hooks:
- Can prove compliance without revealing details
- Can selectively disclose to auditors
- Can respond to law enforcement requests (with warrant)
Benefits:
- Privacy for individuals
- Accountability for crimes
- Regulatory compliance possible
- Fungibility maintained
Challenges:
- Complex implementation
- Who decides compliance rules?
- How to enforce without centralization?
- Game theory: Why would criminals comply?
The Regulation Problem
Jurisdictional fragmentation:
United States:
- Privacy coins often delisted
- Mixers sanctioned
- Strong enforcement
European Union:
- Mixed signals
- Some accept (Zcash ok), others ban (Monero delisted)
- Travel Rule compliance required
Asia:
- China: All crypto banned
- Japan: Requires delisting privacy coins
- Singapore: Pragmatic, case-by-case
Result: No global standard
Compliance difficult
Privacy tools fragmented
The compliance dilemma:
For privacy protocols:
Option 1: Full privacy (Monero)
- Maximum user protection
- But: Delisted from major exchanges
- Limited liquidity, adoption
Option 2: Optional privacy (Zcash)
- Regulatory friendly (transparent available)
- But: Low privacy adoption (only 3%)
- Network effect fails
Option 3: Compliance hooks (proposed)
- Try to balance privacy + compliance
- But: Not clear if regulators accept
- Complex implementation
Option 4: Give up (most protocols)
- Don't implement privacy
- Rely on off-chain solutions
- Accept surveillance
The "tainted coin" problem:
Bitcoin (and others) are NOT fungible:
Coins from Tornado Cash:
- Flagged as "tainted"
- Exchanges may reject
- Worth less than "clean" coins
Coins from old addresses:
- Worth more (provably old)
- "Virgin" coins trade at premium
Coins from hacks:
- Frozen by centralized stablecoins
- Blacklisted by exchanges
Result: 1 BTC ≠ 1 BTC
Different history = different value
Contrary to money's fungibility requirement
Privacy could fix this:
If all coins equally private
→ All coins equally fungible
→ No discrimination possible
But: Regulators oppose
Want to track illicit funds
Fungibility vs accountability tension
The Future of Blockchain Privacy
Technological Trends
1. Zero-knowledge everything:
Current: zk-SNARKs for specific use cases
Future: zk-VMs (zero-knowledge virtual machines)
zkEVM:
- Execute any smart contract
- Generate proof of correct execution
- Keep inputs/state private
Result:
- Private DeFi (trade without revealing)
- Private NFTs (own without revealing)
- Private DAOs (vote without revealing identity)
Status (2024):
- zkSync, Starknet, Polygon zkEVM launching
- Privacy not primary focus yet (focused on scalability)
- Privacy features coming later
2. Multi-party computation (MPC):
Idea: Compute on encrypted data
Example:
Alice has secret X
Bob has secret Y
Want: Compute F(X, Y) without revealing X or Y
MPC protocol:
- Both contribute to computation
- Neither learns other's input
- Both learn output
For crypto:
- Private DEX (match orders without revealing)
- Private auctions (bid without revealing amount until end)
- Private voting (tally without revealing votes)
Status: Research stage, high overhead
3. Homomorphic encryption:
Compute on encrypted data directly:
Enc(A) + Enc(B) = Enc(A + B)
For crypto:
- Private transactions with arbitrary computation
- No trusted setup (vs zk-SNARKs)
- Full privacy + full programmability
Status: Very slow (thousands of times slower)
Research ongoing
Practical deployment 5-10 years away
4. Stealth addresses (Ethereum):
ERC-5564 standard (2023):
- Stealth addresses for Ethereum
- Like Monero's stealth addresses
- Recipient generates new address per payment
Benefits:
- No address reuse
- Receiver privacy improved
- Relatively simple
Limitations:
- Amounts still public
- Sender still visible
- Requires wallet support
Status: Standard approved, low adoption
Needs UI/UX improvements
Regulatory Evolution
Possible futures:
Scenario 1: Privacy banned
Worst case for privacy advocates:
Actions:
- All privacy coins delisted
- Mixers globally sanctioned
- zk-SNARKs restricted
- Mandatory KYC for all transactions
Result:
- Complete surveillance
- Privacy moves to black market
- Offshore/underground usage
- DeFi surveillance-compatible only
Likelihood: 30% (current trend)
Scenario 2: Selective privacy allowed
Middle ground:
Actions:
- Privacy for amounts allowed (confidential transactions)
- Identity still required (KYC at endpoints)
- Viewing keys for audits
- Mixers illegal, but stealth addresses ok
Result:
- Commercial privacy (amounts hidden)
- Identity tied to real world (exchanges, fiat ramps)
- Reduced but not eliminated privacy
Likelihood: 50% (most probable)
Scenario 3: Privacy wins
Best case for privacy advocates:
Actions:
- Privacy recognized as human right
- Light-touch regulation
- Voluntary compliance
- Innovation encouraged
Result:
- Privacy by default
- Optional compliance
- Selective disclosure available
- Privacy normalizes
Likelihood: 20% (requires political change)
Open Problems
1. Privacy + smart contracts:
Challenge: Privacy breaks composability
Public smart contracts:
- Contract A calls contract B
- All states public
- Composability easy
Private smart contracts:
- Contract A cannot see contract B's state
- Cannot compose without revealing
- Limits functionality
Example:
Private lending protocol:
- User deposits (private)
- But: Liquidation bot must detect undercollateralized (needs to see)
- Contradiction
Possible solutions:
- Proof of solvency (ZK proof)
- Threshold decryption (revealed under conditions)
- Trusted execution environments
No perfect solution yet
2. Scalability vs privacy:
Tension: Privacy increases transaction size
Bitcoin: ~250 bytes
Monero: ~2 KB (8x larger)
Zcash (shielded): ~2 KB
With more privacy: Even larger
Result:
- Lower throughput
- Higher fees
- Worse scalability
Solutions attempted:
- Bulletproofs (reduce range proof size)
- Recursive SNARKs (compress proofs)
- Aggregate transactions (MimbleWimble)
But: Still significant overhead
Privacy ≠ scalability (must choose)
3. Privacy + light clients:
Challenge: Privacy requires scanning blockchain
Full node:
- Download all transactions
- Check which are yours
- Privacy preserved (node doesn't reveal interest)
Light client (SPV):
- Ask full node: "Any transactions for address X?"
- Reveals address to full node
- Privacy broken
Solutions:
- Client-side filtering (download filters, check locally)
- Private information retrieval (PIR)
- Trusted servers (defeats purpose)
No perfect solution
Mobile privacy limited
4. Quantum resistance:
Challenge: Quantum computers break current crypto
Ring signatures (Monero):
- Based on elliptic curves
- Quantum computers can break
- Need post-quantum alternatives
zk-SNARKs (Zcash, Tornado):
- Based on pairings
- Also quantum-vulnerable
- Need post-quantum SNARKs
Status:
- Post-quantum alternatives exist (larger, slower)
- Need to transition before quantum computers arrive
- Race against time (10-20 year horizon?)
Conclusion: The Impossible Balance
Blockchain privacy faces an impossible tension: transparency vs privacy.
What we've learned:
1. Bitcoin isn't private:
Pseudonymity ≠ Anonymity
95%+ of addresses eventually linked to real identities
Transaction graph analysis is powerful
Privacy must be added (not inherent)
2. Privacy technologies exist but face challenges:
Mixing: Works but illegal/sanctioned
Monero: Best privacy, but delisted
Zcash: Optional privacy, but 3% adoption
Confidential transactions: Amounts hidden, addresses not
3. Perfect privacy is difficult:
Mathematical: Possible (strong cryptography)
Practical: Hard (UX, scalability, adoption)
Regulatory: Restricted (sanctioned, banned)
4. Trade-offs are unavoidable:
Privacy → Less transparency → Harder compliance
Transparency → Less privacy → More surveillance
Can't have both maximized
5. The future is uncertain:
Technology: Improving (zk-SNARKs, CT, etc.)
Adoption: Limited (network effects, UX)
Regulation: Tightening (sanctions, bans)
The philosophical question:
Is blockchain privacy even possible long-term?
Pessimist view:
"Public blockchains are fundamentally transparent
Privacy layers are band-aids
Eventually regulators will ban/break them
Surveillance will win"
Optimist view:
"Technology advances faster than regulation
Math can't be banned
Private blockchains will coexist
Freedom will find a way"
Realist view:
"Some privacy will exist, but limited
Complete privacy unlikely
Selective disclosure might be compromise
Balance will be found (or not)"
For users:
- Assume everything on-chain is public and permanent
- Use privacy tools carefully (legal risk)
- Separate identities (never reuse addresses)
- Consider privacy coins for sensitive transactions (if legal)
- Accept that perfect privacy may be impossible
For developers:
- Privacy is hard but important
- Regulatory risk is real
- Open source ≠ legal protection
- Consider impact on users
- Build carefully, deploy cautiously
For society:
- Privacy vs transparency is fundamental tension
- No perfect solution exists
- Balance requires hard choices
- Technology alone won't solve it
- Need political solutions too
The search for blockchain privacy continues. Whether it's achievable—or even desirable in its pure form—remains one of crypto's most important unsolved questions.
Prerequisites: Lessons 5.1-9.1, understanding of blockchain fundamentals
Key concepts recap:
Privacy techniques:
- Mixing: Pool funds to break links (Tornado Cash, CoinJoin)
- Ring signatures: Hide sender among group (Monero)
- Stealth addresses: New address per transaction (Monero)
- zk-SNARKs: Prove without revealing (Zcash, Tornado)
- Confidential transactions: Hide amounts (Liquid, MimbleWimble)
Trade-offs:
Anonymity set: Larger = better privacy
Transaction size: Privacy = larger transactions
Regulatory risk: Privacy = potential sanctions
Network effects: Privacy requires adoption
Practice problems:
-
Calculate anonymity set: If Tornado Cash 1 ETH pool has 10,000 deposits and you deposit then immediately withdraw, what's your anonymity set? What if you wait for 10,000 more deposits?
-
Explain why Monero with ring size 16 is more private than Bitcoin with CoinJoin of 50 users. Consider network effects and default behavior.
-
Design a viewing key system for Ethereum. What information should it reveal? What should stay hidden? How would you implement it?
-
Analyze the Tornado Cash sanctions: Were they justified? Consider illicit usage (20%), legitimate usage (80%), developer liability, and freedom of speech (code as speech).
-
Propose a compliance-friendly privacy system that satisfies both privacy advocates and regulators. What trade-offs would you make?
Privacy is a human right, but so is security. The challenge is building systems that respect both—a challenge that remains unsolved.