Combining “Privacy Pools” and “Innocence Proofs”: How to effectively curb illegal activities while protecting privacy?

How to prevent illegal activities while preserving privacy with "Privacy Pools" and "Innocence Proofs"?

TornadoCash uses zero-knowledge proof technology to make fund sources untraceable. Can we find a way to allow users to protect their privacy while effectively curbing illegal activities? Privacy-Pools, developed by one of the early developers of TornadoCash, ameen.eth, proposes a possible direction by combining “innocent proof” with TornadoCash. Cryptography researcher albertlin.eth briefly outlines the mechanism and design principles of this approach.

TornadoCash controls access using receipts called commitments, which are generated by hashing a privacy value and an invalid code. Each commitment can only be used for one withdrawal. Deposit information is recorded using a Merkle Tree structure, with commitments as leaf nodes to calculate the Merkle Root. Users only need to provide the data path from leaf to root to prove that the data is a leaf in the Merkle Tree, thus proving the previous deposit of funds to TornadoCash. The commitment of TornadoCash serves two purposes: proving previous deposits and ensuring a single withdrawal.

The main reason the US government is trying to regulate TornadoCash is that it cannot determine the specific deposit. However, if we can provide another proof, such as zero-knowledge proof, to prove that the funds extracted are not from the blacklist, it may prove that the withdrawal is not related to illegal activities. This concept is called “innocent proof.” The design principle of the privacy pool is based on TornadoCash and adds the concept of “innocent proof.” In the privacy pool, the withdrawal receipt not only has the original purpose of representing the TornadoCash receipt but also has a third meaning, proving that the extracted funds come from deposits on the whitelist. By incorporating this additional proof, the privacy pool aims to provide more guarantees for the legality of extracting funds, ensuring that they can be traced back to authorized deposits on the whitelist.

• ArkStream Capital: Nintendo or Steam? Analyzing the Development Path of Decentralized Gaming Platforms
• Rare sats: A system overview of rare sats. What are the types of rare sats and the search tools available?
• Overview of Flood architecture and use cases: How to solve the problems existing in current RPC system testing?

1) Withdrawal from the whitelist: In addition to providing proof of having a deposit in the Deposit Merkle Tree, proof of being allowed in the whitelist is also required. The corresponding proof of the whitelist should include the Allow Merkle Root and the intermediate node values encountered along the way. 2) Withdrawal from the blacklist: The user’s corresponding deposit position on the whitelist is marked as blocked, and the user is prevented from using the Allow Merkle Root related to the whitelist to withdraw the funds because the corresponding proof cannot be generated.

Reference: https://mirror.xyz/albertlin.eth/6g6RKC_BttfcRhyZ7yvD2Z0B6qd6L4kjRS_gzrsKTlc

We will continue to update Blocking; if you have any questions or suggestions, please contact us!