Satoshi Nakamoto acknowledged Bitcoin's privacy shortcomings as early as section 10 of the white paper, and today's privacy technologies provide more nuanced answers than "anonymity."

Written by: @Lithos_eth

Translated by: AididiaoJP, Foresight News

Bitcoin is public, a consequence of its design. Satoshi Nakamoto knew that openness would bring about privacy issues.

Anyone can verify the transaction history of Bitcoin without needing bank approval. However, the same public record can expose information far beyond what most people imagine. Satoshi discussed this issue in section 10 of the white paper. Since then, researchers and developers have found ways to protect information while maintaining verifiability. How far have we come?

What a Bitcoin transfer exposes

You pay someone Bitcoin. After this transaction is confirmed, it enters a public record that anyone can check.

They can see the inputs, the receiving address, the amount corresponding to each output, and which block the transaction was packed into. They may not know your name. But as long as one of your addresses is linked to an identity, the rest of your activities become easy to trace. Your salary, savings, business transactions, and spending habits can all leave clues on the same public ledger.

For a system that "allows people to transfer money without a bank," this is a strange trade-off. Moreover, Satoshi did not overlook it—there is a section in the white paper called "Privacy," section 10.

To understand where blockchain privacy is heading, we must first revisit what Satoshi actually wrote, examine prior research on Bitcoin, and finally assess what today's privacy systems can and cannot do.

Before Bitcoin, people were already solving this problem

The discussion around privacy in digital currencies did not start with Bitcoin.

In 1982, David Chaum published "Blind Signatures for Untraceable Payments." He studied how an individual could obtain a digital signature for a payment receipt, without the issuer being able to link the receipt to the final payment. This idea is significant because a payment reveals not only "money transferred" but also who transacted with whom, when the transaction occurred, and how often they transact.

Chaum's work established an important direction for digital cash, but his electronic cash model still relied on issuers. Protecting payment information and removing centralized trust are two separate issues. Other researchers and programmers continued to tackle these challenges. The cypherpunks wanted to go further.

In September 1992, a group of cryptographers, programmers, and privacy advocates organized around a mailing list hosted by John Gilmore. The name "Cypherpunks" comes from Jude Milhon, who is said to have used it to refer to the people in the group. Their interests went beyond digital currency to discuss encryption, anonymous communication, digital identity, information freedom, and how individuals could protect themselves with software. Timothy C. May wrote the "Crypto Anarchist Manifesto" in 1988, which circulated electronically during gatherings of the early movement around 1992. On March 9, 1993, Eric Hughes published the "Cypherpunk Manifesto."

One sentence has remained relevant for over thirty years: Privacy is necessary for an open society in the electronic age.

But Hughes had another point that is even more useful for understanding blockchain privacy: Privacy is the power to selectively reveal oneself to the world.

He did not say that people should hide everything, but that individuals should control what they reveal. Stores sell you items without needing your entire financial history; a recipient receiving a payment does not need to see every transaction in your wallet. Hughes candidly stated: The parties involved in a transaction should only know information directly related to that transaction. This idea remains central to privacy discussions today. The cypherpunks also did not believe that privacy would be granted by others—they believed privacy must be created by individuals. Their motto is: Cypherpunks write code.

Several paths to Bitcoin

Bitcoin did not emerge from thin air. Others had already been working on various components of digital currency.

Hashcash (Adam Back, 1997) is a proof-of-work system designed to make certain abuses—including spam—more costly. B-money (Wei Dai, 1998) proposed an anonymous, distributed electronic cash system. Bit gold (Nick Szabo) introduced a digital scarcity value built around computational work, later detailing it in 2005. Reusable Proof of Work (Hal Finney, 2004) tried to make proof of work reusable as transferable digital value.

These are different proposals that are neither Bitcoin nor solve the same set of problems. However, they illustrate the research environment from which Satoshi emerged: people were already seriously constructing a digital currency that did not rely entirely on banks, governments, or centralized payment processors. Satoshi's white paper references Hashcash and b-money.

Bitcoin brought together the ideas from previous works and answered a critical question: How can people reach consensus on a shared payment record without a central authority to prevent double spending? This was a breakthrough that addressed an important issue. Yet, its answer required transactions to be public—that is the trade-off.

What exactly did Satoshi say?

On October 31, 2008, Satoshi Nakamoto published "Bitcoin: A Peer-to-Peer Electronic Cash System." The title of section 10 is "Privacy."

This section first contrasts Bitcoin's public trading model with the privacy accustomed to traditional banking. In banks, transactions are visible to the bank, but the public generally cannot scroll through each person's account history. Bitcoin is different: transactions are publicly broadcast, and users represent themselves with public keys instead of real names.

Satoshi wrote that all transactions must be publicly broadcast, which excludes traditional privacy, but privacy can still be maintained by cutting off the information flow in another place—by anonymizing the public keys.

He proposed methods including using new key pairs for each transaction, making it harder to link different payments to the same person. But he also admitted a weakness: when a transaction uses multiple inputs, it would reveal that these inputs belong to the same owner. If one of those addresses is linked to a real identity, other activities may become easier to connect to that person.

This is a key distinction: Bitcoin's original design offers pseudonymity, not confidential transactions. Your real name will not automatically be written into the ledger like in traditional banks, but the transaction details are public, and off-chain information can help link addresses to real people. Satoshi did not claim this is perfect privacy. He described a method to reduce the connection between public transactions and real identities in a system that requires public verification.

What can be inferred from a transaction?

For a simple example: Lithos wants to pay Emmakun 0.5 BTC, constructing the transaction with her existing unspent transaction outputs. The transaction is broadcast, packed, and added to the blockchain.

External observers can see: the spent inputs, the output addresses, the amounts for each output, the transaction fee (total input minus total output), and the block and timestamp confirming this transaction.

Observers will not automatically know the real names of Lithos or Emmakun. But suppose Lithos received funds from an exchange that requires identity verification, or she posted one of her addresses on a website. In that case, observers might connect the address with an identity. From there, other transactions can be analyzed and correlated.

There is also a complication: a certain output may be a change returned to the sender, rather than paid to another person. Blockchain analysis often relies on assumptions to determine which output corresponds to which. These assumptions are useful, but not always correct.

The key point is: Bitcoin does not need to expose a person's name; the transaction history alone can disclose useful information. Therefore, when discussing Bitcoin, I do not think "anonymity" and "privacy" can be used interchangeably. Its addresses are pseudonymous, and the underlying transaction history is public—these are two very different things.

Satoshi was still thinking about this in 2010.

The 2010 discussion: Where the difficulties of zero-knowledge proofs lie

On August 11, 2010, Satoshi participated in a BitcoinTalk discussion titled "Not a Suggestion." The topic was whether Bitcoin could avoid storing the complete transaction history as it did at the time. The problem centers on double spending: how can nodes verify that a coin has not been spent again without sufficient information to check the transaction history?

Satoshi explained that verifying "nonexistence of double spending" requires a global knowledge of the relevant transactions. He then wrote that it is hard to conceive how zero-knowledge proofs could be applied in this situation.

This statement deserves a second read because context matters. He was not saying that zero-knowledge proofs are useless, but rather discussing a specific issue: how can nodes prove there are no other expenditures existing without knowing all relevant transactions? In other words, how does the network validate "nonexistence of double spending"? This is a different question than "can proofs conceal payment details."

This is important because modern privacy discussions sometimes suggest that Satoshi ignored zero-knowledge cryptography. The historical record is more interesting: he was aware of this idea and was contemplating its difficulty of application to the Bitcoin double-spending problem. In fact, subsequent research has explored how to use zero-knowledge proofs to protect transaction information while enabling the network to verify transaction compliance.

From hiding identity to hiding the payment itself

The research did not stop at Bitcoin.

In 2013, researchers published "Zerocoin: Anonymity for Bitcoin." The paper pointed out a clear limitation of Bitcoin: the public transaction log means privacy largely relies on pseudonymity. Zerocoin explored how to use cryptography to sever the link between transactions and their origins, enhancing Bitcoin's privacy. However, it still exposed the amounts and directions of payments, and the payment method had its limitations.

In 2014, this progress led to "Zerocash: Decentralized Anonymous Payments from Bitcoin." Zerocash proposed a payment system using zk-SNARKs that could hide the sources, destinations, and amounts of transactions while still allowing the network to verify payment validity.

This differs from Bitcoin's original privacy model. Bitcoin attempts to decouple the public key from real identities; Zerocash explores keeping more content of transactions out of the public eye. This is a meaningful shift: the network does not need to see every detail of a payment to check if it complies with the rules. Cryptographic proofs can establish the validity of a transaction without exposing all the information needed to construct it. This is one reason why zero-knowledge proofs are so significant in privacy research.

Today's privacy systems: What each protects

When discussing blockchain privacy, people often categorize all projects under one umbrella. However, hiding the recipient does not equal hiding the amount, hiding the amount does not equal hiding the transaction graph, and on-chain hidden information does not automatically protect off-chain activities prior to transactions. It is worth separating these various paths.

One system may hide the recipient while exposing the amount; another may hide the amount but still leak information through wallets or network connections; a third may allow someone to prove they meet certain conditions without disclosing their complete identity. These represent different types of protections.

Bitcoin and Payjoin. The underlying transaction layer of Bitcoin remains public and transparent, but this does not mean nothing can be done. Developers have found ways to make certain transaction analyses less reliable. The Payjoin Dev Kit describes a method in BIP 78: the sender and receiver collaborate to construct the payment, with the receiver also contributing an input. Why is this important? Some blockchain analyses assume that multiple inputs in a transaction belong to the same person. With Payjoin, this assumption may no longer hold, as the receiver has also contributed an input. However, Payjoin does not hide the transaction amount nor turn Bitcoin into a confidential payment system. It makes certain analyses less reliable—useful, but cannot be conflated with full transaction confidentiality.

Monero. Monero builds privacy into its standard transaction model, protecting different parts of payments through various mechanisms: ring signatures provide sender ambiguity, making it difficult for external observers to determine which output was actually spent; stealth addresses generate one-time receiving addresses, complicating the linkage of payments to the recipient's public address; RingCT hides amounts while allowing the network to verify monetary rules. These mechanisms collectively protect the sender's, receiver's, and amount information.

But there are limitations. The sender's privacy is probabilistic, depending on the transaction rings and the information available to the observer. Monero also uses Dandelion++ to make transaction propagation harder to trace across networks, yet its official documentation warns that this cannot prevent all network observers—users' ISPs, VPN providers, or certain remote node configurations may still expose information. Thus, Monero serves as a useful example of how far transaction privacy can go, but it does not promise that every aspect of user activity will remain invisible.

Zcash. Zcash translates the research on Zerocash into a functioning cryptocurrency. Its shielded transactions protect transaction information using zero-knowledge proofs. When transferring between two shielded addresses, the public ledger does not reveal the sender, recipient, amount, or notes as transparent transactions do, while the network can still verify the transaction's validity. This is much stronger than Bitcoin's original model.

However, Zcash also supports transparent addresses, which means transactions involving transparent addresses remain publicly visible. The usage proportion of shielded transactions, the flow of funds between transparent and shielded pools, wallet support levels, and the anonymity set size all influence the privacy actually received by users. Zcash also illustrates an important idea: privacy and disclosure do not have to be opposites. Its shielded ecosystem includes a view key mechanism that allows for the inspection of selected information without relinquishing spending rights. The specific capabilities depend on the pool and wallet implementation, and cannot assume that every address has the same disclosure capabilities.

The point of comparison is straightforward: Privacy is not a single feature but a set of separate protections. A project needs to clarify which specific aspects it protects. This comparison only describes what external observers can learn from the blockchain itself; it does not gauge IP address exposure, wallet security, exchange records, device breaches, coercion, or information voluntarily disclosed by users. It also does not imply that all privacy protections are of equal strength—Monero's sender protection is probabilistic, while the recipient and amount protections utilize different mechanisms; Payjoin is not an independent currency, but a method for composing Bitcoin payments.

The next question: Privacy within applications

The most significant development since Bitcoin goes beyond cryptocurrencies that hide transaction details. Privacy is becoming part of smart contract and application design. This is important because people do not just transfer money on the blockchain: they transact, lend, vote, manage assets, prove qualifications, and interact with applications. These activities can expose information personal and businesses may not want to make public.

Traders do not want everyone watching their positions; businesses do not want competitors tracking their funds; individuals applying for services may need to prove they meet certain criteria without disclosing their entire identity or financial history. Various technologies are addressing these issues, making private smart contracts increasingly important. Several projects approach this from different angles.

Aztec: An application with both private and public functions. Aztec builds privacy Layer 2 on Ethereum, where smart contracts can simultaneously contain private and public functions. The distinction lies in where the computation occurs. Private functions run in a private execution environment (PXE) on the user’s device, which carries out private computation and generates zero-knowledge proofs, which are sent to the network to verify the required results without sending private inputs to the sorter. Public functions, on the other hand, execute on the network using public state. A single transaction can involve both.

This is programmable privacy: developers decide which parts of the application should remain private and which need to be public, function by function. Take a voting application as an example: a person should be able to vote without revealing their choice, while the final tally needs to be public so that everyone can verify it. The private part handles the ballots, while the public part updates the counts. The application should not need to expose individual ballots while ensuring the final count is verifiable. This is what private smart contracts make possible. The network itself is decentralized, with sorters staking out blocks, permissionless participants, and open governance. Aztec positions itself as one of the few completely decentralized Layer 2 solutions onEthereum, without a central operator controlling sorting or rollups.

However, it should not be overstated. Aztec's documentation states that when a PXE queries the network state—for example, checking whether a certain nullifier exists—the node can know what data the user is interested in. Running one’s own node can reduce this exposure. Private execution does not make all surrounding interactions private. Developers still need to consider public function calls, network requests, transaction timing, and the information the application chooses to disclose. What is interesting about Aztec is not just hiding transactions but giving developers a way to determine which parts of their applications should be private and which should be public.

Oasis Sapphire: A hardware approach to confidential execution. Sapphire uses a Trusted Execution Environment (TEE) to run confidential smart contracts. TEE is a protected hardware environment that isolates data and computation from the rest of the system. Sapphire supports encrypting transaction inputs and the state of confidential contracts, allowing contracts to handle information that should not be publicly visible.

This distinction from Aztec is significant. Aztec’s private functions use client-side execution and zero-knowledge proofs, while Sapphire relies on a protected hardware environment. The two approaches cannot be interchanged. TEE brings trust assumptions around hardware, its security, authentication, and implementation. Zero-knowledge systems have their assumptions, including the correctness of circuits, software, and proof systems. Both methods can be useful, but they differ in how they protect information.

Umbra: Keeping transfers in the shielded pool. I have been following Umbra's work on Solana, particularly the changes from the first version to V2. According to the Umbra team, V1 used encrypted token accounts as a way to deposit into the shielded pool, which acted as intermediaries between these accounts and publicly visible token accounts or other encrypted token accounts. V2 abandoned this setup, focusing on the shielded pool itself: users can conduct private transfers within the pool, rather than moving between multiple encrypted token accounts.

This distinction is important because the pool becomes a place for managing private balances and transfers. But it requires understanding what the pool hides and what it does not. Depositing and withdrawing from the pool may expose information on-chain: observers might see the addresses, assets, and amounts related to the deposits or withdrawals. Timing and amounts can also help people guess which fund movements are correlated. Privacy protection targets activity within the pool. So I would not say this makes every aspect of user activity on Solana private—it protects a specific part of transaction flows. It is still useful but needs to be evaluated against this standard.

Privacy Pools: Proving something without exposing everything. Privacy Pools (built by 0xbow) are compliance privacy protocols on Ethereum and other chains. Users can privately transfer cryptocurrencies while screening deposits to prevent illegal funds from entering the pool. You deposit ETH or stablecoins from an ordinary wallet into a (shielded) pool, and the association set provider (ASP) run by 0xbow screens the deposits, allowing only approved deposits to be used privately. There’s no KYC, nor a global view key. Zero-knowledge proofs allow you to prove that funds come from approved deposits without revealing which specific one, thus cutting the on-chain link between deposits and withdrawals. It is non-custodial and deployed on chains such as Ethereum, Arbitrum, Base, Optimism, BNB Chain, etc. The design is derived from a research paper from 2023 in which Vitalik Buterin was involved. The goal is to offer practical privacy for average users while keeping the pool away from known bad actor funds.

There is another issue I think is important: what if someone needs to prove that their funds meet specific criteria without disclosing their entire transaction history? The Privacy Pools research paper, "Blockchain Privacy and Regulatory Compliance: Towards a Practical Balance," explores a path using zero-knowledge proofs and association sets. Users can prove their funds belong to a set of deposits, without revealing exactly which deposit it is, nor disclosing the entire transaction graph. For example, a user might want to prove their funds are not related to a set of known illegal sources. Proof can establish membership in the association set, but it does not prove a person's overall innocence, nor does it establish that every source of funds is legal. The outcome depends on the information used to construct the association set and the rules applied by the provider. Privacy Pools are an interesting example of selective disclosure: users can prove a specific property without revealing their entire transaction history. This comes closer to Hughes' idea of selective disclosure than a system where all information is either completely public or completely hidden.

Kohaku: What a wallet leaks before a transaction. There is an aspect of blockchain privacy that deserves more attention: an individual may use a private transaction protocol but still leak information through their wallet. When checking balances, wallets typically query remote providers for information on a certain address. This request can inform the provider of which address the user is interested in. Similarly, when wallets request transaction histories, simulate transactions, or obtain information from other accounts, the same issue arises. The transaction itself may be private, but the requests prior to the transaction are another matter.

This is one area Kohaku is exploring. Kohaku is an Ethereum privacy project described as a reference implementation for a privacy-preserving wallet and open-source wallet SDK. Ethereum officials have called it one of the most exciting privacy advances in recent years. Its work covers multiple aspects of wallet experience, including privacy protocols, provider abstraction, light client integration, and post-quantum account tools. One area worth noting is Private Information Retrieval (PIR). In a standard balance query, the server receives the address and returns information. With PIR, wallets can construct queries that return the desired information without revealing which address is being queried. I find this direction exciting because it shifts the discussion beyond transactions. Wallets are where users manage keys, accounts, permissions, and applications. If this layer continues to leak information, merely having private transactions cannot solve the entire problem.

Have we moved beyond Satoshi's privacy model?

I believe the answer is yes, in terms of specific technical capabilities.

If we talk about transaction confidentiality, Monero and Zcash's shielded transactions protect against the payment details exposed by Bitcoin. If we talk about proving the validity of computations or transactions without revealing all underlying information, zero-knowledge systems can achieve this. Aztec brings private execution into smart contracts, Oasis Sapphire uses confidential hardware execution, Umbra focuses on private transfers in shielded pools, Privacy Pools explore how to prove specific attributes of funds without exposing complete transaction history, and Kohaku makes privacy more usable on Ethereum through an open-source privacy wallet and SDK.

These are real advancements. But I won’t say privacy issues have been resolved.

A private transaction does not automatically hide the IP address that submitted it. A private smart contract does not ensure that every public function or interaction is private. A shielded pool does not erase the information exposed when funds enter or exit. A TEE does not eliminate hardware trust assumptions. A zero-knowledge proof does not protect a user whose device has been compromised. A privacy feature that people cannot understand or use correctly may provide less protection than its technical description suggests.

We must look at the entire pathway: wallets, devices, applications, networks, contracts, and the information ultimately revealed. So indeed, there has been real progress, but it needs to be made more usable so that everyone can use it.

What should be public, what should be private

For years, blockchains have been built on公开状态. Anyone can check balances, trace transactions, and analyze activities. This transparency makes independent verification possible, but it also exposes personal and business activities in ways that are difficult to justify.

I do not think every part of a blockchain should be hidden—you see I advocate for selective disclosure. Public institutions should be held accountable, public spending should be scrutinized, and networks should provide ways for people to verify that rules are being followed and statements about their operation can be corroborated. But I also do not believe a person's savings, income, private payments, investment positions, identity documents, and business activities should automatically be public just because they are on a blockchain.

These demands can coexist. A person should be able to prove they qualify for service without disclosing every detail of their identity. Businesses should be able to settle payments without exposing their entire financial situation to competitors. Voters should be able to vote secretly while ensuring the final results remain publicly verifiable. Wallets should be able to check balances without revealing to remote providers which accounts users are interested in. These arguments do not call for hiding everything but rather for giving control over disclosures back to individuals.

That is why I return repeatedly to Hughes's definition of privacy: Privacy is the power to selectively reveal oneself to the world. It is far more useful than simply asking, "Does the project have private transactions?"

Bitcoin opened an important part of this work but did not complete it. Each time I read section 10 of Satoshi's white paper, what stands out the most is not that Bitcoin failed to address all privacy issues but that Satoshi understood and acknowledged the tension between an open trading system and individual privacy, proposing a pragmatic compromise within the design he was building. For many years, cypherpunks have been asking a broader question: How can people use digital systems without disclosing unneeded information? Bitcoin answered an important part of that. Subsequent developers have pushed the work further. Chaum explored untraceable digital payments, Zerocoin and Zerocash advanced transaction privacy, and Monero and Zcash brought different forms of confidential payments into use.

So have we surpassed Satoshi? In certain technical capabilities, absolutely. But the broader aim of cypherpunks is not just to hide transactions but to empower individuals to control what they disclose without losing the ability to verify important matters. Updated systems bring privacy into smart contracts, wallets, identities, and selective disclosures. Each approach has different advantages and limitations. This is also what I want readers to keep in mind when evaluating privacy projects: look beyond the statements on the website, beyond the technical names, beyond whether a transaction is described as private. Look at what the system actually hides, what remains visible, understand who can access information, what assumptions the system relies on, and what happens when people use it in the real world.

The original question posed by cypherpunks still deserves to be asked: Why should a system know more information than it needs to perform its function?

Bitcoin made it possible for individuals not to rely on banks for currency verification. The current work is to give people more control over what information they disclose while retaining the ability to verify matters. This is the part of the privacy movement I want to continue researching.