Technical Deep Dive: Tornado Cash

•

"Privacy isn't criminal," snapped Tornado Cash V2. In 2022, the US government slapped sanctions on @TornadoCash Breaking down of V1 & V2 mechanisms, introducing the groundbreaking concept of a "privacy pool," while unraveling the core privacy issues. 0/19 🧵🌪️

Bookmark thread as these knowledge is a must if you work in crypto 1️⃣ Why Tornado Cash 2️⃣ V1 Mechanism *V2 (tweet 12-18) 3️⃣ What is Proof-of-Innocence? 4️⃣ What is Privacy Pool?

1️⃣ Why Tornado Cash? In the crypto world, privacy matters. But while Tornado Cash offers protection, it has also faced money laundering sanctions. V1 safeguards your privacy, V2 makes it legit.

2️⃣ V1 Mechanism: In every transaction, there are two roles: sender and receiver. Tornado Cash's goal is to hide the identity of the sender in a transaction. Even if the transaction is recorded on the blockchain, the sender's identity remains untraceable.

Pooling Fund: By pooling all incoming funds into a large pot, when a withdrawal is made, it's only known that the funds came from this crypto mixer.

Mixer with fungibility concept. Unlike fiat money with unique serial numbers, 1 ETH is identical to someone else's 1 ETH. The previous state before the mixer remains unknown.

Users can only deposit fixed amounts into Tornado Cash: 0.1 ETH,10 ETH… By making all deposit and withdrawal amounts the same, it's impossible for anyone to track wallets by amounts deposited or withdrawn.

Who can withdraw? You need "Receipts", similar to a deposit claim ticket. However, receipts aren't generated by the smart contract but are provided by users depositing funds to keep everything invisible.

Problems: If Bob uses Alice's receipt to withdraw, it's clear that the money came from Alice, defeating the purpose of sender anonymity. Two techniques are used to solve the proof of deposit: 👉🏻 Merkle Tree & nullifier 👉🏻 Zero-Knowledge Proof (ZKP)

Using a Merkle Tree to record info: Receipts are created by hashing a 'secret' and a 'nullifier' to form a "commitment". In Tornado, this commitment is added as a leaf at position r6 in the Merkle Tree.

Data structure: The Merkle Tree structure proves data's leaf status by providing parent hash values from the leaf to the root. To verify if r6 (green) is a leaf, provide the data in the blue boxes.

Nullifier to prevent double withdrawal When users make a withdrawal, they must provide the hash value of the nullifier (hash(nullifier)). If this value already exists in the Tornado Cash contract, it indicates the deposit has already been claimed

ZKP to prove a deposit is made on Tornado. Use r6 example again, we only need to provide r6, r5, H(r7,r8), and H(H(r1,r2),H(r3,r4)) to verify the merkle root, without revealing their actual content.

V1 Technical Recap: 👉🏻 A receipt (commitment), generated from a secret and nullifierHash, each receipt can only be used once. 👉🏻 Use Merkle Tree to record deposit information 👉🏻 Use Zero-Knowledge Proof to hide the source of the deposit

3️⃣ What is Proof-of-Innocence? Core concept is to show the withdrawal isn't linked to illegal actors, by proving the withdrawn funds: from the allowance list / not from the rejection list

The diagram below demonstrate that the withdrawn funds aren't from the deposits on the rejection list (marked in red)

4️⃣ What is Privacy Pool? Privacy-Pools introduce the concept of "Proof-of-Innocence”. A withdrawal receipt from the pool can prove the funds come from the allowance list. If a hacker deposits money, we'll update the "Allow Tree" to block it.

Legal Scenario: To verify the funds, the user must provide "proof of deposit" and "proof of being allowed". If the Merkle Root matches the user's Allow Merkle Root, verification is successful. Thus, the funds originate from a U.S. government-approved deposit.

Illegal Scenario: If a hacker without a deposit on the U.S. government's allowance list tries to withdraw funds, and the corresponding deposit location is marked 'blocked'. Hackers must provide an alternative Allow Merkle Tree to withdraw funds.

Illegal Scenario Cont.: Using a self-generated or untrustworthy Allow Merkle Tree increases the likelihood of withdrawn funds coming from problematic deposits, which can be tracked by the government.

Can you fake a "root" to take money? Yes, but the mechanism is aware of funds from the rejection list, making legal action easier for the government. This design prevents anyone from having control over fund withdrawal, ensuring decentralization.

Huge credit to these resources: medium.com/taipei-ethereum-meetup/breaking-down-tornadocash-a-beginners-guide-to-explaining-its-functionality-to-friends-7227fcda5942 medium.com/taipei-ethereum-meetup/tornadocash-v2-privacy-pools-%E5%8F%8A-proof-of-innocence-4c19e8967adb github.com/tornadocash/tornado-core

Tornado Cash V2 updates to tackle hackers: @CRYPTO_TAG @GemsofRa @DLocalTrader1 @lemiscate @theweb3nova @PeckShieldAlert @RileNFTs @MetaSleuth @whalenjennings @crypto_ert @rot13maxi @alexanderchopan @swaggyAlexyXv2 @CryptoTHFC @CryptoAndAliens @wholisticguy

Tagging my frenz to discuss privacy issues: @0xSalazar @DeFi_Cheetah @Alvin0617 @2lambro @Slappjakke @crypto_linn @defl_mochi @splinter0n @ViktorDefi @Dynamo_Patrick @goldflakes_eth @CryptoNikyous @poopmandefi @0xJamesXXX @Hercules_Defi @wacy_time1 @CryptoShiro_