• Base Camp: Why Mixers Are Hopium
• Camp 1: Why Privacy L2s Are Hopium
• Camp 2: How UTXO chains using Pedersen Commitments with rings were broken (Monero)
• Camp 3: UTXO with SNARKs (The Death Zone)
• The Summit: Account Model with El Gamal

Onchain privacy means an outside observer cannot see where a specific balance comes from, or goes to. Or even whether, in case of hidden balances, the money is where it was when an output was created or has been spent.  

This probably wasn’t the definition of privacy Satoshi had in mind initially. Satoshi originally believed Bitcoin was private because addresses weren’t tied to real life identities. It was a user called Bytecoin, who showed up in BitcoinTalk in 2010, who made the case that since for every Bitcoin balance we can see where it came from and where it goes when spent, Bitcoin is in fact not private but pseudonymous. 

Satoshi retired (“moved on to other things”) shortly after Bytecoin’s posts. Probably because that’s when he realized Bitcoin lacked a fundamental property digital cash is supposed to have, and that this flaw couldn’t be corrected without Bitcoin ceasing to be Bitcoin (as Bytecoin would explain in many posts at length). The way Satoshi left was noteworthy, as he opted for a soft exit rather than a loud goodbye. 

Satoshi is not a single person or entity, but a collection of the most advanced engineers working on crypto at every point in time since the Bitcoin WP was published in 2009. Back then, Satoshi was an individual or a tightly knit team. Few years later, that Satoshi grew out of the initial team/person when the first outsider, Bytecoin, proved to have leapfrogged his/her/their understanding of onchain privacy. From that point onward Satoshi became much more ethereal, and remains ethereal to this day as he absorbs more engineering talent with time.

His soft exit is noteworthy because in reality it’s as if he never left, he just morphed into something else that resembles a nameless identity for the deep and uncompromising awareness of the challenges of onchain privacy. 

So as Satoshi kept evolving, from a single voice it turned into hundreds of whispers whose agency was manifested every time there was a breakthrough in addressing the onchain privacy challenges first discussed by Bytecoin. It’s no coincidence, I think, that all major breakthroughs in onchain privacy at the protocol level have come from other anonymous identities that also soft exited after doing their part to help crypto take another quantum leap forward. All these identities are a manifestation of the same awareness that keeps expanding with time, Satoshi.

The questions you are probably asking yourself now are: What else did Satoshi build or experiment with? Where can these decentralized Satoshi whispers be heard these days? What are they saying and debating? 

The first step to meeting Satoshi today is to set aside the this is good enough for me mindset. Remember, Satoshi stopped being a single voice in 2011 as soon as he realized Bitcoin wasn’t private. That was 15 years ago, before trillions of dollars worth of new cryptocurrencies were created with the same identical privacy flaw. He didn’t wait, he didn’t brush off Bytecoin’s criticism as FUD, he didn’t censor or delete his posts. He simply went back to the drawing board right away.

Satoshi wasn’t tribal and wasn’t interested in hopium. He was strictly a tech person and a realist. This is why those looking for hopium will never meet him. And let me add a quick disclaimer here: I’m not related in any way to Satoshi, I am not an engineer, coder or mathematician. I haven’t bumped into any golden leaks of people who made it into the inner circles of the Satoshis out there either. I’m a textbook outsider. I’m an observer who has been taking notes for a long time and through careful listening has found a way to the peaks where those whispers can be heard today. 

The starting point is privacy. If you think about it, that makes sense since Satoshi *morphed into something else *right after Bytecoin explained why Bitcoin could never be private. He deeply cared about privacy and that triggered his first footstep into exploring more of the unknown ahead of him. By paying close attention at what has been happening in the privacy space since then, we can find many other footsteps of Satoshi that lead up to the current highest peak. To get there however we’ve to climb through the entire privacy tech spectrum, and reject hopium at every level. Hopium is what gets people stuck because it glosses over the deep flaws that pushed Satoshi himself to move on. 

§Base Camp: Why Mixers Are Hopium

Those stuck in transparent chains like Bitcoin try to make their coins difficult to trace by outsiders by mixing them with other coins owned by other people. Some famous mixers you’ve probably heard of are Coinjoin, WabiSabi and TornadoCash (Eth). Most people agree Coinjoin is trivial to trace, but still think WabiSabi and Tornado Cash are good enough, especially since regulators have gone after them and their devs. In reality, as I’m about to explain, they’re all trivial to trace.

Wabi Sabi mixes different UTXOs from different users through multi input and multi output transactions. Since users can specify the number of outputs they want, and split amounts, amount analysis is much more difficult than usual. In other words, you can insert 1 BTC, and request 3 outputs with 0.1, 0.7 and 0.2 btc on 3 fresh addresses. 

The naïve take is that….the privacy guarantee of Wasabi defies intuition….consider a round with 400 inputs and 1400 outputs….the analyst must solve a variant of the subset-sum problem…The problem is P-complete…

Well, not really. The theoretical privacy guarantee of the mixer could be a mathematical problem, but in reality the solution is much simpler because the problem is mathematical only for as long as we’re mixing with perfect strangers, which is not the case in practice. If, for example, the coordinator of the mixer is an analyst then the analyst can insert 399 of his own outputs and those of his partners, and make sure there are only few “real users” in each round. This would effectively break the privacy of the mixer since we would be able to find out the outputs of the few real users by filtering out our own outputs and those of our partners. But even if the coordinator is honest, an outside analyst could still flood each mix round with their own outputs making the outputs of real users easy to connect. Or he could analyze other behavioral metadata of other participants who don’t have strong opsec, and by linking their outputs he would be able to expose the target’s outputs through exclusion.

In Tornado Cash money is pooled together in a pool and each participant is given a receipt that allows him to spend from the pool an amount equal to their initial deposit. The same attack vector can be applied to Tornado Cash. If an analyst spams every pool with his own inputs, making sure there are few real users at every round, then those users can be easily unmasked by filtering out the receipts controlled by the analyst and his partners. Or, again, if most users don’t have good opsec the flows of those with perfect opsec can still be unmasked through exclusion.

For these reasons it’s no surprise that Satoshi flat out disappeared and didn’t waste his breath discussing mixers.

§Camp 1: Why Privacy L2s Are Hopium

The second wave of solutions explored has been the development of L2s where transactions are private, for example Railgun on ETH. Each L2 has its own magic tech for privacy inside the L2, for example some use zero knowledge proofs, others use TEEs, and some even FHE. The fundamental problem with all L2s is that privacy can be broken by analyzing entry/exit points and entry/exit amounts, which allows building some sort of liquidity flow charts. And again, the privacy guarantee is still only as strong as the opsec of the residual liquidity within the L2. If the existing liquidity is tagged/reported, then the liquidity added by random users can be easily monitored.

L2s don’t add fungibility to the L1, they decrease it. Because the L1 is transparent and traceable, every balance that originated from a privacy L2 can be flagged. At the same time every balance trying to enter the L2 can also be monitored before it’s accepted in the pool (eg: when required to generate POI, aka proof of innocence). Therefore in practice, privacy L2s become a way of extracting more behavioral metadata from users.

Regardless of how advanced the privacy tech inside the L2 box is, any form of digital cash that relies on an L2 for privacy becomes less fungible, less private and less trust less (since L2s are always more centralized than the L1). This is why despite some people trying to argue L2s are good enough, because they offer compliant privacy by controlling entry and exit points, Satoshi just moved on. 

§Camp 2: How UTXO chains using Pedersen Commitments with rings were broken (Monero)

The first real attempt to address privacy onchain at the protocol level was Cryptonote, which was released in 2014 by an anonymous identity known as Nicholas Van Saberhagen (NVS). NVS built the first protocol blueprint for privacy by default by implementing at the protocol level: mixing at each transaction through ring signatures, key images (a receipt that could be published only once to prevent double spends), single use outputs and “stealth addresses”. This opened a new frontier that would, iteration after iteration, lead to what is today’s implementation of Monero.

§A few words on Stealth Addresses

Users never share any existing onchain address with others. Instead, they share a unique, static public address that each sender would use to generate a unique one time stealth address that would be owned (and spendable) only by the receiver. 

The implications were huge. Contrary to Bitcoin, if Alice accepted donations in Bytecoin (the first implementation of Cryptonote), I could no longer query the blockchain for her public address to see how many donations she was receiving. Because every person donating would put their donation inside a new address (“stealth address”) that was generated by the sender of each transaction by combining Alice’s public address with a random secret number. And there was no way, for an outsider, of tying these new outputs to the public address they were generated from. 

§A few words on Key Images

Key images were another innovation of Cryptonote, since thanks to key images we no longer had to empty outputs onchain (ie: update their balance to 0 like we do with BTC). The balance of outputs actually never changed once they were created/engraved onchain. Instead, they were “emptied” through the publication of a receipt known as key image that only the owner of an output could own and publish. 

The core issue with Cryptonote was that an analyst could still map the flow of money by analyzing amounts, outputs’ age and other metadata (such as transaction type) to find the real spend among ring members (mixins) in each transaction. Once the real spend was identified, it meant we knew which output the key image belonged to and could draw a transaction graph of how the money flowed from the real spend(s) to the new outputs created in that transaction. 

§Why single use outputs and key images still haunt Monero today

To mitigate these issues in Monero, an important upgrade introduced Pedersen Commitments at the UTXO level to hide the balance of each output, as well as RingCT that made possible building rings out of these new outputs to hide the real spend among15 decoys (in today’s implementation). While the introduction of PCs made amount analysis impossible, with time it would become clear that single use outputs and the UTXO model forced unavoidable behaviors that would always leak patterns unmasking the real spender among ringCT members.

Ironically, the very same innovations first introduced by NVS at the protocol level turned out to be the ultimate unfixable weaknesses that would haunt Monero up until the very end, despite the many mitigation upgrades.  Because when combined together, these weaknesses (the patterns they leak) can be exploited to deanonymize any transaction, no matter how good the OpSec.

§Camp 3: UTXO with SNARKs (The Death Zone)

The next frontier in privacy tech was the introduction of zero knowledge proofs at the protocol level through SNARKs. This was considered the Holy Grail for a while, but there are plenty of cues that Satoshi discarded this direction, probably over security concerns. Contrary to UTXO with ringCT, Zcash transactions (the first implementation of SNARKs) consist only of the key images (called ‘nullifiers’ in Zcash) of the outputs being spent, the new outputs being created with them, and a “zero knowledge proof” generated by spender’s wallet that proves that the nullifiers passed all the verification “tests” required to prove that they belong to existing outputs among those present onchain. 

These verification tests are a series of constraints that every spender must satisfy when trying to build a transaction to send money somewhere. They aim to prove that the outputs being spent actually exist onchain, have never been spent before, the spender is authorized to spend them, he is providing valid nullifiers belonging to them, and the sum of the balances of inputs is equal to that of outputs. 

These constraints have to be engineered in a so called “binary circuit”, which is a group of tests (like a bar exam) about specific constraints a transaction must pass. Once the constraint test checks out, the binary circuit issues a receipt (“like a bar exam certificate”) proving that the transaction passed all checks and should be accepted. Other nodes in the network can verify that this receipt is legitimate by inserting it in the local binary circuit. 

This proof however is only as good as the binary circuit itself. Just like we trust a bar exam to have enough good questions to make sure that someone who hasn’t studied law cannot pass it, we also have to trust a binary circuit is checking enough constraints that an invalid transaction would never be able to pass it. Because once a transaction passes the verification check it is accepted as legitimate by the entire network. The other network participants never see the actual inputs to the proof, they never verify them on their own. They can only verify that the existing SNARK circuit checks passed, and have to trust that whoever designed that SNARK took everything into account and didn’t let anything slip through the cracks. 

As you’re probably guessing right now, this lack of ability to verify is SNARKs’ Achilles’ heel. Cryptographically this is known as the “soundness” of SNARKs, ie their completeness in logic to be always able to block invalid transactions. This “completeness” however cannot be proven mathematically, we’ve to trust the engineers that devised it. The risk is a soundness bug in the SNARK logic, which would be fatal for the entire network.

Perhaps this is also why Zcash has opted for optional privacy all along. Not because of compliance, but as a technical necessity to make sure an inflation bug remains detectable. If most of the liquidity is on unshielded notes (transparent ZEC) then any exploiter would have to unshield his coins first, and since the amounts going in and coming out of the shielded pool can be seen, any inflation bug would be easily detectable that way if all of a sudden more coins started coming out of the shielded pool than those going in. 

Because of the weaknesses tied to single use outputs when combined with rings, Monero is also aiming to move toward a ringless implementation through Full Chain Membership Proofs. FCMPs are also a type of zero knowledge proof that focuses on proving membership. In other words, this is a system of constraints that is engineered to act as proof that the output being spent is present onchain and has never been spent before, and that the key image in the transaction belongs to said output, and that the sum of inputs and outputs checks out. The problem, again, is that we cannot verify homomorphically, like we can do with Pedersen Commitments with RingCT, that the sum of inputs and outputs is the same. Instead we have to trust the soundness of the FCMP circuit to do so. But again, just like with SNARKs, its completeness cannot be proven mathematically.  

So while Monero may improve privacy with FCMP, Satoshi would probably advise against it because of the huge trade off in verifiability. 

§The Summit: Account Model with El Gamal

Like explained in Camp 2, despite the many patches and upgrades, Monero’s privacy today is still broken by analyzing for onchain patterns leaked by single use outputs and UTXO behavioral patterns. 

• In April 2025 Monero Research Labs revealed that they developed a system (OSPEAD ) capable of filtering out 11 out of 15 decoys just by analyzing output age

• Co-spend (“cluster”) analysis is a well documented heuristic as well. In any transaction where related outputs appear together the real spends are those related outputs. Related can mean anything from belonging to the same age band to originating from the same CEX

  

• Just like with Bitcoin mixers, the privacy guarantees of rings are only as good as the quality of the decoys and the quality of decoys in Monero can be easily destroyed by spamming the network with spam transactions. This increases the odds that the decoy picking algo picks 15 spam outputs as decoys and therefore reveals the real spend in rings. We saw this attack vector shortly after Incognito started blackmailing its own users in March 2024.

The only way to eliminate these heuristics is to abandon the UTXO accounting model for the account model, and to replace Pedersen Commitments with El Gamal ciphertexts. The Zether whitepaper is the first place where this combination was attempted, and in the words of the Authors they were forced to abandon Pedersen Commitments because they are not public key updatable or re-randomizable:

One might wonder why we do not just use Pedersen commitments… A Pedersen commitment to a value v with randomness r is g^v*h^r. If Alice transfers some amount to Bob, she cannot simply update Bob’s Pedersen commitment because she does not know the randomness r used in Bob’s commitment. She would have to communicate the new randomness to Bob… Using public-key encryption directly [ElGamal], as we do, avoids this issue. 

The practical implications of this were then pioneered at the protocol level by DERO, which was also launched by another anonymous identity (“Captain”). By opting for the account model with El Gamal, an analyst can no longer construct a transaction graph by monitoring the blockchain because we don’t have new outputs created after every transaction, and because the balances of senders and receivers are updated homomorphically, they’re not emptied (as they’re not single use). So we no longer can draw an arrow from the real spender(s) to the new outputs saying whatever balance these spenders had, is now sitting in these new outputs. 

By using homomorphic encryption with the account model it is possible to achieve a system where the construction of the transaction graph is no longer possible, and this doesn’t come at the cost of verifiability because we avoid binary circuits by resorting to homomorphic additive verifiability instead.