The title is what I felt when I read about a new paper on Privacy Pools, that other projects dedicated to cryptocurrencies would like to implement in the near future. I confess that I read it about four times and didn't understand it crearly, but on the fifth try, with a little help from BingChat to delve into the more technical details, I finally understood it. But I ended up disappointed, I won't deny it.

One of the central points when using cryptocurrencies is pseudonymity. We are not anonymous on a blockchain because there will always be digital traces or crumbs we leave behind, but still, a blockchain can record an event without considering the real identity of the individual or entity. We know a transaction occurred, that's it, and that's the point.

There are different types of transactions, and the folks at Samourai Wallet have turned this into an art by explaining in various articles about transactions and their potential shortcomings. When it comes to privacy, these guys are always on my list of people who know what they're talking about.

So what happened here? For years, the Ethereum ecosystem has been looking for different options to improve user privacy, to not be too exposed, and, to me, the best option in that market (not the only one, but the best in my opinion) is Tornado Cash, a software that allows (in short) increasing the entropy of your transactions through collaborative transactions, using a technology called zk-SNARK that basically allows verifying a transaction without revealing who sent it, where it was sent, and the amount sent. Tornado Cash maintained a pool of funds where users made collaborative transactions, and there were no traces of sends or deposits.

So far, we've introduced the characters and what they do, and now the problem: the cap, as the young people say. Tornado Cash has been mentioned countless times in reports of financial crimes for allowing individuals engaged in illegal activities to use this software for crimes similar to money laundering and others. In fact, several developers were even arrested for writing code, which is the most ridiculous thing in the world.

Imagine this: you wrote software, and other people use it for illegal activities, but you get the worst part just for creating it. In fact, Tornado Cash has made several adjustments to comply with the regulations required by the OFAC to the point of creating hybrids to comply. But that wasn't enough.

Enter this new paper with Chainalysis, Vitalik Buterin, and people related to Tornado Cash as the main actors. The paper proposes Privacy Pools that will have something called exclusion proofs or membership proofs, based on zk-SNARKs.

How would it work? The exclusion proofs or membership proofs will primarily aim to prove that the deposits and withdrawals made by users do not come from or belong to a set of associations that don't meet certain criteria. Simpler? A regulatory body will feed the protocol with addresses, transactions, and other data. Then, the user could prove that their money has a good reputation since it does not belong to the set of associations marked by the financial authority.

Privacy pools serve as an intermediary to:

As often happens, and as I had written before in NOSTR, there are things that the code has nothing to do with; it's the soul of the project. In this case, the problem is being approached from the wrong perspective.

One of the authors is associated with Chainalysis, a company dedicated to blockchain analysis and tracking of illicit activities. It all sounds good, but here's the big problem: they use mechanisms and technology that are deficient. Who says that? The company itself, which admitted to using unverified tools and methods that are not really proven. In other words, to track illicit activities, this company gathers information that is not really useful or collects it through questionable methods.

We start from the conception that AML/KYC regulations are good, and that's the central core of the problem, linked to problem one, which is errors and false positives. To give you an idea, there are ongoing legal proceedings today using evidence collected with problem 1. To this, we must also add the arrest of people linked to the software who basically never touched a penny involved in illicit activities, yet they are arrested for participating in those activities. Simpler? AML/KYC regulations are very ambiguous, allow data abuse, discriminate based on socioeconomic profiles, and have a host of disadvantages because these regulations are not the same worldwide.

Remember Pantagruel? He ate everything: fish, cheese, wines, and when that wasn't enough, he even ate thoughts and more. It was never enough for him, and he always needed more. What happens with these regulations and others? When you open the door to an authoritarian entity, it will never end: first, they'll ask for one thing, then they'll ask for more, and here's the problem: like Pantagruel, it will never be enough, there will always be a hunger for more and more. Before you know it, you'll have created a system that aids in censoring blocks, transactions, and addresses, becoming synonymous with the traditional financial system.

No matter how much judicial authorities feed it, the concept of a blacklist is completely gray. In addition to the problems mentioned earlier, we are creating a dangerous monster to control because you are feeding it with assumptions, and it will eventually trigger problem 2.

The problem being addressed is that the State intends to continue controlling two things: technology and monetary policy. This paper, while it has the best intentions, and we understand the problem it wants to address, has voluntarily shifted the Overton window towards centralization. We are taking risks for financial authorities that use rather vague laws, and above all, it goes against the nature of a blockchain. We return to the central point that Satoshi Nakamoto proposes: not depending on intermediaries to move transactions.

To this day, there are different proposals and solutions working on the issue of privacy, in fact, there are tools that are quite viable (Whirlpool, GrapheneOS, Linux), and while we understand what it intends to solve, it will actually make it more ambiguous.

But this is my opinion, and we should continue discussing this.

Published first in NOSTR: naddr1qq2hy4fd2p4yvcf5fp9j6ne32ayxvjz2wadz6q3qpps3gnrkt6ssuwdys3e62xlwvpygdcv2h58cx8x9a4m9re52rjhsxpqqqp65wrwzv9p