First, here, we need to admit that Bitcoin has a problem: Its transparency is a design flaw, which Satoshi knew about, didn’t know how to fix, and underestimated the impact of. Mixers are a Band-Aid on a gaping wound. Bitcoin’s blockchain is like publishing your bank statements in an append-only database on the Internet.
I wouldn't call it a design flat, I'd call it a design
choice. It's a choice that brought Bitcoin where we are today.
No. Satoshi didn’t choose this. He
wanted to build Bitcoin differently, but he didn’t know how. Not to knock Satoshi! It’s a hard problem. In 2008–2010, the needed technology didn’t exist.
This post will eventually have the maximum 100 merits from me. The list of people who have sent it merit thus far is interesting: Bitcoin experts and legends, privacy advocates, both Zcash and Monero users.Merited by nullius (50), garlonicon (20), o_e_l_e_o (4), Foxpup (3), ABCbits (2), Hueristic (1), BitcoinFX (1)
This is a very interesting topic. If a solution was found, a much better, easier, more convenient implementation of Bitcoin would be possible.
Originally, a coin can be just a chain of signatures. With a timestamp service, the old ones could be dropped eventually before there's too much backtrace fan-out, or coins could be kept individually or in denominations. It's the need to check for the absence of double-spends that requires global knowledge of all transactions.
The challenge is, how do you prove that no other spends exist? It seems a node must know about all transactions to be able to verify that. If it only knows the hash of the in/outpoints, it can't check the signatures to see if an outpoint has been spent before. Do you have any ideas on this?
It's hard to think of how to apply zero-knowledge-proofs in this case.
We're trying to prove the absence of something, which seems to require knowing about all and checking that the something isn't included.
I don’t want to make this a Zcash v. Monero issue here, but I will state briefly my own opinion: The system that Satoshi wished for was
exactly what Zcash implemented. It’s called “commit-and-nullify”. The basic design was invented in the 1990s
*, and it solves the double-spend problem; Satoshi evidently just didn’t know about it. However, for a practical, private, and secure implementation on a blockchain, the needed cryptography was not developed until 2013–2016 (
Zerocash research followed by zk-SNARKs edited for precision: Zerocoin research, followed by zk-SNARK research and Zerocash (which led to Zcash))... or arguably 2019–2022 (the Halo2 proof system), if you demand
no trusted setup. The way that it works is a mind-bender: You, and only you validate your own transaction—but you run the validation program inside a Turing-complete arithmetic circuit, which proves in zero knowledge to others that you ran the program validating your own transaction.
The consensus validation code then validates your public proof that you privately validated your transaction. 
🤯
The Monero people will surely have their opinions, and I respect their advocacy of privacy and fungibility.
Quick edit to add: Another goal that Satoshi apparently sought there is not yet deployed in any coin that also provides privacy, although Zcash carefully chose their elliptic curves to support recursive zero-knowledge proofs for this. (I should fill in details later by edit and/or later reply.)Bitcoin devs were discussing all of this in 2013, right here on this forum; we still don’t have it in 2026.In this message I offer a brief start of a proposal for improving the scalability, flexibility, privacy, and fungibility of Bitcoin. [...] In
SNARKs for C: Verifying Program Executions Succinctly and in Zero Knowledge (referred to as SCIP below), Eli Ben-Sasson et al. describe their work on highly efficient non-interactive proofs with zero-knowledge for the faithful execution of programs written in C. Eli also
presented at the Bitcoin conference.
^^^ The technology wound up in an altcoin, Zcash, when it should have been in Bitcoin.
Now compare Monero, which is banned from centralized exchanges in EU-countries. Owning Monero isn't illegal, but governments don't like privacy and want an ever growing amount of information about everyone. If Bitcoin would offer on-chain privacy, chances are it would be banned, and I'd argue banning Bitcoin doesn't make it better.
You forget the
fait accompli factor that I described earlier in the thread.
If privacy and fungibility had been built into Bitcoin early, then advocates thereof would have stood on the high ground of accomplished facts. But accomplished facts went in the other direction. The discussions bore no fruit. What should have been an MVP feature of Bitcoin v0.1.0 was shunted over to an altcoin. And the precedent was set for Bitcoin to be a surveillance-coin that’s like dumping your fucking bank statements into a public append-only database.
The precedent is hard to undo. And now, upon that precedent, the noose is being tightened.
With regard to CEX listings, Monero is fighting an uphill battle against the Bitcoin precedent of a transparent blockchain. So is Zcash; they’ve had some success with a different strategy, but sometimes I fear their strategy may entrap them into compromising the project. So is Litecoin’s MWEB, which has suffered some substantial prejudice from CEXes.
Even the term “privacy coin” is prejudicial: It implies that non-privacy is the default and expected mode of operation for a blockchain.
If Bitcoin had been a “privacy coin” from the Genesis Block, or even if it had had privacy added around 2013 when some Bitcoin devs were interested in integrating
Zerocash edited for precision: Zerocoin/Zerocash, then privacy would be the default expectation.
* I need to provide references. I’m writing this in haste off the top of my head, and I don’t currently have access to my old notes. Much though I dislike editing posts, I will edit this space later to add some academic-style references.
Apologies to others, I’m slow, and I need to catch up here later. “Warning - while you were typing 2 new replies have been posted. You may wish to review your post.”