Bitcoin is a permanent open ledger whose privacy features have mostly been defeated by blockchain analysis. Every transaction, after being confirmed into a block, is considered final (though some will argue that waiting for six confirmations is the more conservative way to guarantee permanence). And once this transaction has been added to the ledger, anyone can analyze it for as long as the network stays online — and this scrutiny can continue offline if someone stores a complete copy of the blockchain. In other words, Bitcoin is a pseudonymous panopticon which derives its privacy from the idea of deniability: the more users participate in the system and accept to be paid directly for BTC, the harder it becomes to certainly associate addresses and transactions with identities of real people.

But in the era of blockchain analysis, when most on-ramps and off-ramps are subjected to KYC/AML procedures, breaking the deniability is easier than ever. And privacy, while it appears to be decent at the moment when the transaction occurs, can only degrade over time as the sender and the receiver may accidentally or willingly divulge more information later on. Satoshi himself wrote this in the whitepaper: ”some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking would reveal other transactions that belonged to the same owner” [1].

While some self-described ”toxic maximalists” will argue that Bitcoin is inherently fungible at the protocol level and discrimination is only an issue at the social layer, it’s nearly impossible to not distinguish between monetary units while the origins are clear. In June 2024, PayPal co-founder Peter Thiel has made one of the most candid observations on the topic: ”when people in the FBI tell me that they’d much rather have criminals use Bitcoin than $100 bills, it suggests that maybe it’s not quite working the way it was supposed to” [2].

Regardless of this depressing status-quo, there are three types of arguments to be made in favor of Bitcoin’s aspirations to become a private digital currency: the first one concerns the history and origins of the project, the second one is about sound money and the requirement to obtain fungibility, and the third is about some efforts that developers have made over the years.   

1. Bitcoin’s History and Cypherpunk Origins

In an e-mail that he sent to b-money inventor Wei Dai in August 2008, Satoshi Nakamoto attached a document called ”ecash.pdf” [3] — an early draft of the Bitcoin whitepaper whose working title implies the creation of a decentralized approach to David Chaum’s privacy-friendly electronic cash system. At chapter 10, just like in the final draft of the Bitcoin whitepaper which was revealed to the world on October 31st, readers can find a rather naive but useful description of how bitcoiners can transact with a degree of privacy: every time a user receives bitcoins, he should generate a new ”public key” whose purpose and identity are known only by the sender. This method was also demonstrated by Satoshi Nakamoto while he mined blocks: currently, the ”1 million BTC” theory is a mere assumption that Sergio Demian Lerner has made during his Patoshi research in 2013 [4]. We cannot know for certain which blocks were discovered by Satoshi, as every coinbase reward of 50 BTC was sent to a different address.

According to professional software engineers who analyzed version 0.1 of the Bitcoin software, Satoshi Nakamoto was not a seasoned C++ developer. He created a system that was pieced together from open source libraries, included a broken game of poker and a peer to peer marketplace, and made it available only on Windows. It took the efforts of other developers such as Hal Finney, Gavin Andresen, Jeff Garzik, Mike Hearn, Wladimir van Der Laan, Gregory Maxwell, and Laszlo Hanyecz to refine the code, break it down into manageable chunks, and port it to Linux, MacOS, and mobile platforms. Satoshi Nakamoto’s amateurish and “hacky” coding style was attested by early contributor Jeff Garzik [5] and Libbitcoin maintainer Eric Voskuil [6]. 

Based on these observations, as well as some e-mail exchanges in which Satoshi appeared to be insecure about his project and seemed to look up to Hal Finney, we know that the Bitcoin creator wasn’t some time-traveling alien AI who invented digital alchemy (as Saylorists seem to believe) and he wasn’t a CIA/NSA professional either. Satoshi didn’t invent or write from scratch the building blocks of Bitcoin: elliptic curve digital signatures, Merkle trees, SHA256, Proof of Work, public key cryptography, peer to peer networks, electronic cash and blockchains were all available as separate iterations that served distinct purposes. But he did want Bitcoin to be a decentralized version of Chaumian ecash — a true holy grail among the cypherpunk community.

The above paragraph, though it may seem unnecessary in the context of a discussion on privacy, is useful in providing context for what kind of software developer Satoshi was and what his intentions were. We do know that he wanted his system to have privacy, but at the same time he wasn’t the best coder or cryptographer around. He merely used the open source libraries that were available to him at the time. And most of the privacy technology that emerged later (ring signatures, zero knowledge proofs, MimbleWimble, confidential transactions, ZK rollups) marks an attempt to improve on a rough software stack and bring it closer to fulfilling its mission.

We know with certainty that Satoshi Nakamoto cared about improving Bitcoin’s privacy because, during his short tenure as lead developer and educator in chief he provided feedback to some early improvement proposals. This intellectual contribution is frequently pointed out by Monero fans, who claim that their network of choice closely follows the writings of Satoshi. 

On August 11th 2010, as part of Bitcoin Talk’s 770th thread (titled ”Not a suggestion”), Satoshi Nakamoto replied to users Red and Insti who proposed using Zero Knowledge Proofs to minimize the amount of transaction data being stored by full nodes. Initially, the Bitcoin creator made a pretty interesting suggestion: ”if a solution was found, a much better, easier, more convenient implementation of Bitcoin would be possible.” [7]

Two days later, under the same forum topic, Satoshi described three elements that lay at the foundation of today’s Monero and ZCash:  

”Can public nodes see the values of transactions?” — a condition which later inspired the creation of Confidential Transactions.

”When paying to a bitcoin address, you would generate a new blinded key for each use” — a vague description of stealth/shielded addresses and Silent Payments, as well as one-time public keys.

”I think that’s where group signatures comes in. With group signatures, it is possible for something to be signed but not know who signed it.” — a description of what would later become ring signatures in Monero and mixing pools in ZCash (as well as CoinJoins in Bitcoin).

Satoshi Nakamoto didn’t only answer to the comments posted by the users, he also proved that he’s been researching the topics and presented the limitations of his discovery: ”Crypto may offer a way to do ‘key binding’. I did some research and it was obscure, but there may be something there. ‘Group signatures’ may be related.”

As always, the Bitcoin creator presented a practical example to spark the imagination of the contributors: “say some unpopular military attack has to be ordered, but nobody wants to go down in history as the one who ordered it. If 10 leaders have private keys, one of them could sign the order and you wouldn’t know who did it.”

Satoshi also encouraged others to find a solution to a problem he couldn’t solve during his short tenure as lead developer: “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?”

Hal Finney, legendary PGP coder and the first notable cypherpunk to give Bitcoin a chance, is responsible for putting out the famous “Running bitcoin” tweet — published on January 11th 2009. But only 10 days later, he wrote about a lesser known but equally significant effort: “Looking at ways to add more anonymity to bitcoin” [8]

This post was sent out to the world two years before Silk Road was launched, and it would take five years for the intelligence company Chainalysis to get founded. Without fueling any “Hal Finney was Satoshi” theories, it’s worth noting that his early concerns were valid and haven’t been dismissed yet. Bitcoin never received more anonymity — just a little bit more deniability via transaction obfuscation. 

2. Sound Money Requires Fungibility

Now let’s talk about the properties of sound money — a status which Bitcoin unquestionably aspires to attain. Even in the event that it scales down its purpose to remain a store of value, a certain degree of fungibility is still required. Currently, discrimination of transactions is possible at the validator and block producer level: nodes can choose to filter out transactions of arbitrary types or coming from a certain source, while miners can ignore transactions that they don’t like (most famously, Ocean Pool filters ordinal inscriptions and MARA Pool rejects addresses on the OFAC list).

The reason why Bitcoin still works as designed is the incentive system: it’s relatively easy for the sender to spin up a node which saves his transaction in the mempool and keeps on broadcasting it — any contemporary computer can run Bitcoin Core or Libbitcoin. Likewise, for every censorship-friendly mining cartel, there can always be another independent block producer who will not mind collecting the transaction fee.

However, in a world in which KYC/AML practices become prevalent and blockchain analysis is an industry standard, there is a lot more information about Bitcoin users, addresses, and miners. So resourceful governments can pressure participants into following a strict blacklisting procedure, with very draconian punishments for miners who break the rule. Naturally, geopolitical game theory fixes part of the problem because we live in a multi-polar world with a plurality of superpowers that don’t always collaborate. But a project like Bitcoin should not rely on goodwill or flaws in the structure of human politics — instead, it should become censorship resistant by design. The only way to achieve this feat is to make it impossible for miners to act in ways which differ from the system’s incentives: therefore, collect the highest fees to confirm transactions without caring about the origins. If Bitcoin adds a degree of confidentiality, which enables senders to remain private and also hide the amounts that they’re sending, then the system would finally support sound money.

As any monetary theorist will tell you, fungibility is a very important quality for good money. An ounce of gold is equal in value with another one of the same purity, regardless of its origins. A $100 bill will buy you the same amount of goods and services, even if it was previously held by Brad Pitt, the President of the USA, a construction worker, a convicted criminal, or all of them at different times. In the case of Bitcoin, you still encounter “freshly mined coins”, “Silk Road coins”, “dark market coins”, “Mt. Gox coins”, “Coinbase coins”, “Kraken coins”, “CoinJoined coins”, “ordinals”, and all sorts of ways to differentiate according to origin. On the free market, freshly mined coins are usually deemed more valuable — for the simple reason that they have no past.

Interestingly, Bitcoin does have a built-in fungibility mechanism: once a transaction fee gets paid, the corresponding coins get mined again as part of the block reward. So even the most “tainted” coins can become squeaky clean once a miner collects them as fees and reissues them. However, this is not enough: and to expect all “tainted” bitcoins to get sent as transaction fees is extremely unrealistic. What Bitcoin needs is a system that makes it impossible to discriminate according to previous ownership — and if users (and outside observers) cannot know, then they will have no means to censor.

3. The Proposals to Make Bitcoin Private

Almost sixteen years into Bitcoin’s existence, we have a remarkable series of discoveries and inventions that can improve its privacy. Some of them are already part of the Core software stack (such as BIP32, whose hierarchical deterministic wallets help create more deniability) or exist as additional features in various wallets (such as CoinJoin in Wasabi, JoinMarket & Samourai, or Silent Payments in Cake Wallet). But these solutions alone aren’t good enough. They generate a degree of deniability, but can’t hide the amounts being transacted and are generally worse for the sender.

This is why we must look into the plethora of more or less experimental proposals which offer privacy with various tradeoffs. Most commonly, there are three types of criticism regarding anything which concerns Bitcoin privacy:

1. That the extra obfuscation occupies more blockchain space and therefore won’t scale, as is the case of Confidential Transactions and Ring Signatures (both available on Monero);
2. That hiding transaction amounts may lead to unwanted monetary inflation in the event of bug exploits, as the money supply is no longer easy to audit;
3. That privacy of any kind might get Bitcoin delisted from exchanges, banned from certain jurisdictions, or even scare away institutional investors who put billions of dollars into building their BTC portfolios while assuming that the software is complete, stagnant, and easy to audit by regulators;

The first two issues can be avoided via elegant cryptography, cautious development, and rigorous testing. Privacy enthusiasts can launch the new features on other networks, incentivize scrutiny and adversarial interactions, and then propose their refined discoveries to the Bitcoin community. However, even the ideal solution becomes useless if there is no social support for its implementation in particular or for anything that aims to fix Bitcoin privacy in general. If the culture gets eroded by complacency and “number go up” hopium, then the desire for fiat money gains will stall any cypherpunk aspiration — it won’t be until fungibility really becomes an issue which blatantly erodes the financial well-being of a majority of users that the conversation about adding privacy becomes serious.

Politics aside, it’s useful to pay attention to breakthroughs in the world of privacy, understand how they work, and think of ways to apply similar protocols or principles to Bitcoin (preferably, without requiring major changes to the consensus code). It’s how ideas get refined and distilled into their most efficient form. It’s also how clever workarounds get discovered, as means to circumvent the conservative nature of the Bitcoin protocol.

The 4 types of Bitcoin Privacy

Before proceeding with the analysis, it’s important to distinguish between the four types of Bitcoin privacy: sender, receiver, amounts, and network-level. For a more thorough breakdown on the topic, I recommend you to listen to Paul Puey on S15 E48 of the Bitcoin Takeover podcast [7].

When used as Satoshi suggested in the whitepaper (new address for every incoming transaction), Bitcoin protects the identity of the receivers — that is, until further multi-input transactions are made to break the deniability. If the user makes use of the Tor network or a powerful mixnet such as Nym, then other peers cannot figure out where the node or light wallet is located based on IP address. So Bitcoin can also have pretty good network-level privacy.

However, there is little to no privacy for the sender: as the receiver can see the amount being sent and how much change was returned after the transaction. And speaking of amounts, there is no way to have any confidentiality for the number of coins being transferred — at least not on the base layer.

A good way to get deniability when sending Bitcoin is to transfer the entire amount from the UTXO to avoid change. This can be interpreted as a self-transfer to a new wallet, but can also be a payment. Nobody really knows initially, unless the veil gets lifted later when a KYC/AML off-ramp gets involved or someone makes a mistake.

There are several significant proposals to address these shortcomings, and they will be presented according to the issue they address. 

Dandelion++ for Network-Level privacy

For example, Dandelion was created to significantly boost network-level privacy by inserting a random delay that breaks the link between IP addresses and individual transactions. It was proposed for Bitcoin in 2017, received a significant improvement (Dandelion++) the next year, but it never made into the Bitcoin project. Though there was some interest from developers, the users never really pushed for the adoption of this particular privacy enhancement — and if you ask the average bitcoiner today, they won’t know what Dandelion is and probably assume you’re speaking about a “shitcoin”. The protocol was however added to Monero, Firo, and a bunch of other privacy projects. It would have been great to have it in Bitcoin, since it doesn’t require any kind of fork or consensus and none of the concerns listed above would apply.

MWEB for Sender Privacy & Hiding Amounts

The MimbleWimble Extension Block protocol was also proposed for Bitcoin, but ended up getting developed for Litecoin. Back in 2016, Blockstream head of research Andrew Poelstra presented the idea to put MimbleWimble (a novel and groundbreaking privacy and scalability protocol) on an extension block [8]. This integration would require a soft fork and enables bitcoiners to peg their coins into a larger anonymization pool where the amounts being sent are hidden and you can’t lurk into someone else’s address. 

All you can observe in MWEB is how many coins join the pool, where the peg-ins come from, and where the peg-outs go. Though the latter two points might sound like an issue, they can be mitigated with CoinJoins to create enough deniability to make analysis difficult. 

MimbleWimble comes packaged with confidential transactions — a technology that was built for Bitcoin, was picked up by Monero, but scales much better in the updated design of Tom Elvis Jedusor. It has been available on Litecoin since May 2022 and still works flawlessly, with mobile integrations and light wallets being developed in recent months to increase portability. 

Historically, Litecoin is the network that tests upgrades which are considered to be too risky or avant-garde for Bitcoin — it happened in the case of SegWit, then it continued with main net Lightning Network experiments that were later moved to BTC. However, this time around there seems to be no interest in adding MWEB: there is no BIP to promote it, there are almost no debates about it, and critics usually point out to MimbleWimble and say it’s not ”good enough” for privacy (as if other proposals are seriously being considered or else there is something that Bitcoin already has). 

Can MWEB scale? Absolutely! Thanks to the embedded data compression, it prunes older transactions and remains compact in size. Block size increases can be applied to it without really requiring more storage from nodes. It’s also designed in a way which makes the supply easier to audit — anyone can see how much liquidity exists in the anonymity pool, and then nodes can reject amounts that exceed the peg-ins. But will it lead to exchange delistings? As Litecoin demonstrated, not really. Only a couple of Korean exchanges did that due to regulatory uncertainty. The big players never dropped support. MWEB is an opt-in layer for transactions — and businesses can still operate on the main chain if they want to have full transparency. 

It’s definitely a useful and interesting proposal which does contribute towards fixing Bitcoin’s privacy and scalability issues. However, as revealed in S15 E17 of the Bitcoin Takeover podcast, not even Andrew Poelstra (the man who first thought of putting MimbleWimble on a Bitcoin Extension Block) is passionate about the idea anymore… not even after it’s been implemented on a Bitcoin-compatible network [9]. But if you want to hear a technical and somewhat optimistic discussion on the topic of MWEB, listen to S15 E59 with David Burkett — the man who made it all happen [10]. 

Statechains, CoinJoins & PayJoins for Pragmatic Sender Privacy

Statechains, CoinJoins, and PayJoins (payments coming directly from CoinJoins) at scale can also mitigate some of Bitcoin’s privacy issues. The sender’s privacy definitely gets a boost, but amounts being moved on the main chain remain visible. With Statechains, currently developed by CommerceBlock for the MercuryLayer, users can seamlessly swap UTXOs of equal sizes without leaving any permanent record on the base layer. It’s a pretty cool concept, as the transfer of ownership happens without the blockchain. To learn more about it, listen to my interview with developers Nicholas Gregory and Tom Trevethan [10]. 

However, the incentive to perform this swap only exists when you don’t want your further transactions to carry your identity. And if UTXO swapping is exclusive to those who need it, then the coins being exchanged aren’t necessarily ”the cleanest” that everyone wants. This is why CoinJoins should be used in conjunction with Statechain CoinSwaps — so that all the bitcoins involved are equally clean and equally dirty at the same time. Paying out of CoinJoins is also necessary in order to preserve the privacy benefits.

However, the user experience for following this process is still cumbersome and the cost might be a little too high for most people (especially in a high fee environment, which Bitcoin expects to have). But even if Bitcoin does scale and the interfaces do get optimized to serve non-technical users, there still needs to be enough demand for this type of privacy. The reason why privacy is still niche is that very few bitcoiners actually use it.

Drivechains for Pretty Much Everything 

One of the most interesting, yet controversial proposals to improve Bitcoin is Drivechains: Layer Two Labs CEO Paul Sztorc has come up with the idea of miner-enforced sidechains that copy the features of every altcoin. This way, the scaling solution also acquires the benefits of  adding functionality and utility. Basically, Drivechains fulfill the dream of Bitcoin maximalism — that of having every use case and every transaction on Bitcoin, within the economy provided by the 21 million supply cap. The concept is explained by BIP 300 and BIP301.

In terms of privacy, Drivechains come packaged with a Zcash sidechain that provides the most advanced privacy that’s available today (as it’s a direct fork of the latest version of Zcash). It’s called Zside and can be downloaded from the LayerTwo Labs website for testing purposes on the Bitcoin signet. To use it, bitcoiners must transfer their coins into the sidechain and lock them for approximately 13000 blocks (the time frame between the deposit and the withdrawal was architected like this to ensure system stability). On the base layer, the coins get frozen in a time lock contract. On the Zside chain, the same amount of BTC gets minted and becomes usable for as long as the user keeps the funds pegged.

This means that the supply is always clear, the amount of coins locked in the Zcash sidechain can be verified, so there is no risk of hidden inflation. By virtue of being a sidechain that can choose to prune transaction history after a certain point, it’s also very scalable. And in terms of regulators banning it or exchanges delisting BTC, they’d have to enable support for this particular layer first. Bitcoin remains unaffected.

Of course, some Bitcoin Core developers such as Matt Corallo and Peter Todd have expressed concerns about mining centralization and MEV (Maximal Extracted Value) [11]. But Paul Sztorc is currently working on the CUSF (Core Untouched Soft Fork) activation method, which involves bypassing the opinions of Bitcoin Core by directly dealing with the miners [12]. Since the block reward is diminishing and the amount of transaction fees collected by the miners is disappointingly low, there’s an incentive for block producers to enable merged mining. Drivechains also come bundled with blind merged mining, which is really useful in this multi-chain context.

If implemented, Drivechains open up the technical possibility for Bitcoin to onboard the entire planet and provide all the smart contracts or privacy features that one might desire. But at this point in time, it seems like the community would rather discuss covenant soft forks and OP code restoration than think bigger in terms of what the Bitcoin network can be. It seems unlikely that Core developers will agree on activating BIP 300, but the miners might just coordinate to maximize their revenue — because to them, the next few years are going to be all about the fees.

Covenants for ZK Rollups & Trust Minimized Sidechains

While they don’t provide any privacy benefits by themselves, covenant soft forks such as OP_CTV, OP_CAT, and OP_ANYPREVOUT are tools which allow developers to build trust-minimized sidechains and ZK rollups. With covenants, layers such as Liquid and Rootstock (which today rely on trusted setups or federations) can significantly improve their decentralization. 

Also, as suggested by Bitcoin developer Super Testnet, Drivechains could get built using OP_CAT and BitVM — but there are some tradeoffs in terms of user benefits and protections that make the Drivechains soft fork activation preferable. 

ZK rollups are also an interesting import from Ethereum, which allows users to transact with pretty good privacy on scalable layer twos. Projects like Citrea and Alpen Labs already exist and work towards building proper rollups for Bitcoin, but their ability is still limited by the lack of specific features unlocked by covenant soft forks.

Covenants can also support the creation of CoinJoin implementations that don’t have a coordinator in the middle. Something like Wasabi Wallet can get built in an automated manner, without central servers. The research of 1440000000 bytes (also known as ”Floppy”) is definitely interesting and can lead to a future in which CoinJoins are uncensorable and much easier to use.

It’s also worth noting that StarkWare, a protocol which brings Zcash-level privacy using Zero Knowledge STARKs (Scalable Transparent Arguments of Knowledge), can come to Bitcoin. Eli Ben-Sasson, the mastermind behind the system, has previously worked with ZK SNARKs (used in Zcash) and has been speaking about bringing privacy and instant blockchain synchronization to Bitcoin since at least 2014. He also co-authored the Zerocash research paper and has been on a journey to refine Zero Knowledge proofs for BTC for almost a decade.

ZK STARKs are already available on Ethereum. But if Bitcoin activates OP_CAT (or else the StarkWare researchers figure out how to build it without the extended function), then we can see this avantgarde cryptographic magic coming via ZK rollups. Not quite the ideal way, which would involve making standard base layer transactions private, but in tune with the philosophy to scale in layers with various benefits and tradeoffs.

The future is promising for these concepts, though some community members express concerns about the ability to build anything using concatenations (OP_CAT). Regardless, the privacy provided does not directly impact normal 1 input-2 outputs transactions on the base layer and it’s not as good as adding opt-in Zcash transactions. But this appears to be the path that gets most ”consensus” among bitcoiners, as many of them seem to agree that a covenant soft fork is useful.

It’s also worth noting the existence of projects such as Bitcoin OS which claim they can emulate the features of a covenant without any soft fork, and therefore allow Bitcoin to ossify and become ”permaware”. It’s an interesting approach, but it comes with limitations and tradeoffs that get fixed by an actual network upgrade. In 2024, I’ve recorded interviews with pretty much all the big players in the covenant and ZK rollups space — from Robin Linus and Orkun Kilic to Liam Eagen, Alexei Zamyatin, Eden Yago and Super Testnet. You’ll find many of these conversations if you scroll through season 15 of the show!

Privacy Hard Forks

Now we’re stepping into the field of high fantasy, as the goal is to dream about Monero or Zcash-like features on Bitcoin. However, a more radical change to the protocol, which implies a hard fork, does not necessarily lead towards better privacy. In the end, privacy is achieved when there are lots of participants who use the same protocol for the purpose of becoming indistinguishable from each other.

So it doesn’t make much sense to fantasize about Confidential Transactions (available today on Liquid) or Ring Signatures. Also, Zcash’s ZK SNARKs or Halo2 cryptography probably won’t come to Bitcoin any time soon. The reasons don’t only concern political/regulatory concerns, but also the scalability argument — anything that generates larger transaction sizes within the small block framework is less desirable.

But we can also look at projects like Decred, which managed to make every on-chain transaction a Wabisabi-like CoinJoin (CoinShuffle++, in which the amounts are visible, but there’s a lot of deniability for the sender) and also make the Lightning network more stable. I’ve interviewed Decred’s Jake Yokom-Piatt and Phoenix Green in S15 E55 of the Bitcoin Takeover Podcast and I think it’s a really interesting conversation from which we can learn [14].

Ultimately, I believe that Bitcoin will integrate a more mature version of Zcash’s protocol. It will come in a time of crisis, when institutional adoption proves to be a fad and the users find themselves desiring for ways to hide from oppressive governments. Since day one, the Zcash protocol has been thought as a way to improve Bitcoin — and Zcash’s similarities in design (21 million coins, initial Proof of Work mining) are no coincidence.

Hard forking to add privacy is the final boss — a moment that culminates a long series of social-political experiences and technical experiments. Bitcoin will undoubtedly choose to become sound money by employing the most mature, well-tested, and efficient protocol available. This is why the users, instead of being complacent, should be engaged in testing features on altcoins in order to identify the implementations that show potential and get ready for the moment when Bitcoin must get something similar. 

As mentioned in the first part of this article, it’s important to demolish any suspicion of hidden inflation. It’s also important for the privacy protocol to be scalable to the point that private transactions don’t come in larger data sizes (which is why it appears that ZK proofs might take us there). 

Last but not least, privacy should be the default and universal setting — users must never have to deal with a perishing fungibility that gets ruined by one bad actor who holds the coins, and they shouldn’t know a world where privacy is stigmatized either. Nobody questions you today when you hand a dollar bill to somebody else in a public place. Nobody will question you in the future for sending a peer to peer digital money transaction to a stranger, using a public, inclusive, and socially-mundane payments network. It’s just how evolution works.

Bitcoin will one day be 100% fungible — and we need to prepare for that day, both technologically and socially.

Bitcoin Is Still a Panopticon

Given the volume of information presented, we can safely affirm that allowing Bitcoin to have very poor privacy today was a choice. It might be the result of negligence or cowardice on behalf of the users and developers. It may be a consequence of the ”number go up no matter the cost” mentality, combined with the fear of getting delisted from exchanges. It’s possible that the efforts to please regulators, portray Bitcoin as the nice chain that criminals avoid, and eventually embed in into the traditional financial system via ETFs might have be part of the reason. But regardless of the cause, the situation is not great: not for the users, not for the network, and definitely not for the fungibility of the currency.

Sure, CoinJoins are fine — but they still reveal the amounts being transacted and some of the participants might later KYC to diminish the others’ deniability. CoinSwaps via Statechains (as designed by Mercury Wallet) are also useful, but you never know when you get a much more ”tainted” UTXO than the one you sent out. The CoinJoin outputs may be considered ”tainted” and therefore unacceptable by some economic actors. Until the moment Bitcoin gets privacy for the amounts being sent, these issues will continue to affect users.

Since Hal Finney’s ”Looking for ways to add more anonymity to bitcoin”, which he published 18 days after the Bitcoin network launched, internet money nerds have aspired to reach this goal without any technical roadblocks or social/political issues. Almost 16 years later, we have much better research and development in the field of privacy. A decade from now, we will have perfected these tools. What matters the most is to not capitulate to dinosaur institutions offering us Sim City cheat code money, and also to try to not feel jaded about the apparent lack of progress. Technology will get us there — but are we ready for it?

Sources:

1. The Bitcoin Whitepaper, Satoshi Nakamoto, 2008, Available at: https://bitcoin.org/bitcoin.pdf 
2. Peter Thiel on Aspen Ideas Festival 2024, Available at: https://youtu.be/B3ZXrTzskw0
3. Nakamoto Studies Institute, Electronic Cash Without A Trusted Third Party, Available at: https://www.nakamotostudies.org/literature/ecash.html 
4. Sergio Demian Lerner, ”The Well-Deserved Fortune of Satoshi Nakamoto, Bitcoin Creator, Visionary and Genius”, April 2013, Available at: https://bitslog.com/2020/06/22/a-new-mystery-in-patoshi-timestamps/ 
5. Jeff Garzik, ”Hemi Presents Satoshi Stories — The Secret Behind Satoshi’s Real Identity”, Available at: https://youtu.be/Zi92Y0WpEg4?si=yYwU5TiQKZfmVwal
6. Erik Voskuil on the Bitcoin Takeover Podcast, S5 E8, Around 00:20:51, May 2020, Available at: https://bitcoin-takeover.com/audio/index.php?name=2020-05-13_s5_e8_eric_voskuil_on_misean_economics__cryptoeconomics.mp3
7. Satoshi Nakamoto on the Bitcoin Talk Forum, Replying to Topic #770, In response to Red, August 11th 2010, Available at: https://bitcointalk.org/index.php?topic=770.msg8637#msg8637 
8. Andrew Poelstra at SF Bitcoin Developers, November 21st 2016, Available at: youtube.com/watch?v=aHTRlbCaUyM 
9. Andrew Poelstra on the Bitcoin Takeover Podcast, S15 E17, February 8th 2024, Available at: https://bitcoin-takeover.com/andrew-poelstra-bitcoin-covenants-op_cat-vs-op_ctv/ 
10. David Burkett on the Bitcoin Takeover Podcast, S15 E59, October 14th 2024, Available at: https://bitcoin-takeover.com/audio/index.php?name=2024-10-14_s15_e59__david_burkett_on_mweb_privacy.mp3 
11. Nicholas Gregory and Tom Trevethan on the Bitcoin Takeover Podcast, S15 E25, March 24h 2024, Available at: https://bitcoin-takeover.com/audio/?name=2024-03-24_nicholas_gregory_tom_trevethan_on_mercury_layer.mp3
12. Peter Todd, ”Drivechains: A Detailed Analysis”, October 13th 2023, Available at: https://petertodd.org/2023/drivechains 
13. Paul Sztorc, ”CUSF — Core Untouched Soft Fork”, v0.4.1 published on June 23rd 2024, Available at: https://bip300cusf.com/cusf.pdf 
14. Jake Yokom-Piatt and Phoenix Green on the Bitcoin Takeover Podcast, S15 E55, September 21st 2024, Available at: https://bitcoin-takeover.com/audio/index.php?name=2024-09-21_s15_e55_jake_yocom-piatt_phoenix_green_on_bitcoin_decred_privacy.mp3
15. Hal Finney, Personal Twitter Profile, Available at: https://x.com/halfin/status/1136749815