That question framed five days of adversarial reasoning at Casa21 (Vinteum's hackerspace in São Paulo). From September 21 to 25, developers and researchers with different levels of experience gathered for another Vinteum Deep Dive. We started by thinking like chain analysts: what can we infer from Bitcoin’s transaction graph, which assumptions make those inferences possible, and how far can a handful of imperfect heuristics take us? Then we switched sides and studied how those assumptions can be broken: Payjoin, CoinJoin, CoinSwap, wallet behavior, and attempts to make privacy a property of normal Bitcoin usage rather than something users have to preserve manually.
This is one of the habits we try to cultivate in our Deep Dives: understand a system well enough to challenge it. Read the papers, specifications, and code. Identify the assumptions they rely on. Try to break them. Then understand what survives.
This time, our scope was deliberately narrow. Bitcoin privacy is a much broader problem, and we left important areas largely aside, including peer-to-peer network privacy, transaction broadcast, and approaches designed to hide amounts or other transaction data. Instead, we focused on on-chain transaction privacy: what an observer can infer when the underlying transaction data remains public forever.
The goal was not to produce a comprehensive survey even within that narrower scope. We wanted to understand what exactly someone can learn by looking at the blockchain, which conclusions follow directly from what is recorded there, which depend on heuristics and assumptions, and what happens when privacy protocols deliberately make those heuristics less reliable. The harder question came afterward: once ambiguity has been created, how long does it survive?
By Friday, we had a much clearer framework for thinking about those questions. Chain analysis looked less like an oracle and more like a difficult inference problem, while privacy looked increasingly fragile as small leaks accumulated over time.
Privacy is not a luxury
Privacy is a fundamental aspect of what makes money usable. Ordinary financial life depends on the assumption that paying someone does not automatically give them access to your financial history, that competitors cannot reconstruct your company's cash flows from every payment it makes, and that anyone in the world cannot inspect your balance and spending habits simply because they interacted with you once. When financial activity can reveal who you know, what you support, or where you are, privacy becomes closely tied to personal safety and freedom.
Unfortunately, Bitcoin does not provide those guarantees by default.
Its ledger is intentionally public. Anyone can join the network, obtain its history, and independently verify that the rules have been followed. That ability to verify without permission is one of Bitcoin's fundamental properties. But it comes with an uncomfortable consequence: the same data available to validate the system is also available to analyze its users.
This does not mean that public verifiability and privacy are inherently incompatible. It does mean that Bitcoin's current design exposes a great deal of information, and any attempt to recover privacy has to operate in an environment where transactions remain available for analysis indefinitely. Accordingly, we have to think of privacy as a dynamic property. What an analyst can infer from a transaction today is not necessarily what they will be able to infer from it tomorrow. Every new transaction adds information to the graph. Coins are spent again, counterparties reveal themselves, wallet behavior becomes easier to fingerprint, and new analytical techniques can be applied retroactively to transactions that have been public for years.
A privacy assessment is always a snapshot. Ambiguity that exists at one point in time can shrink as the graph evolves.
For us, the interesting question is therefore not whether Bitcoin can provide some privacy, it clearly can. The question is how much privacy survives against an adversary that is patient, has access to the entire transaction graph, and keeps learning.
Start by becoming the analyst
We began the week from the attacker’s side. Before evaluating techniques designed to frustrate chain analysis, we wanted to understand the inference problem an attacker is trying to solve. A common beginner’s model of Bitcoin privacy is centered on addresses: avoid address reuse and transactions become difficult to connect. Address reuse is indeed an obvious privacy leak. But modern chain analysis is not primarily a matter of finding reused addresses, nor is it a matter of blindly applying a single heuristic. Analysts combine multiple signals, each useful under different conditions.
The analyst wants to cluster the addresses it finds on the chain. Imagine beginning with every address or script as an isolated object. Then observe transactions and repeatedly ask whether there is evidence that two of those objects belong to the same wallet, service, or economic actor. Every plausible inference lets clusters grow. Perfect clustering would mean linking each and every bitcoin address to an economic actor, a task achievable only by an abstract omniscient observer.
It is useful to separate what the blockchain actually tells us from what a concrete analyst infers from it. Inputs, outputs, scripts, amounts and transaction ordering are observations. Common ownership, change, wallet identity and economic relationships are interpretations built from those observations.
The common-input-ownership heuristic is particularly powerful because co-spending is strong evidence of common control in ordinary transactions. Collaborative transactions deliberately create exceptions by allowing multiple parties to contribute inputs to the same transaction. But making a heuristic false in some cases does not mean that a competent analyst will simply continue applying it indiscriminately. The more interesting question is whether the analyst can identify the transactions in which the heuristic should not apply and, if so, whether other signals allow the ownership partition to be reconstructed anyway.
Then there is change detection. If one output looks like the payment and another looks like change, the change output can be pulled into the sender's cluster. When that output is spent later, the cluster grows again. Change detection is especially useful because it lets an analyst propagate an inference forward through the graph. If an output can be identified as change, later spends of that output provide additional opportunities to extend the same cluster.
Other signals can include amounts, transaction structure, ordering, timing, script types, coin-selection behavior, and eventually fingerprints left by particular wallet implementations. These signals also differ in scope and reliability. Some may apply broadly but provide weak evidence. Others can be highly discriminating but only for transactions produced by a particular wallet, script type, or period in Bitcoin’s history.
In practice, the analyst’s problem is not to find one universally correct heuristic, but to combine conditional signals without allowing false positives to contaminate otherwise unrelated clusters. The problem we wrote on the board was almost algorithmic: start with many isolated clusters and use observations of state transitions to merge them whenever the evidence supports doing so.
None of these heuristics needs to be a proof. That distinction became one of the most important lessons of the week. An analyst rarely gets to say, with mathematical certainty, that two addresses belong to the same person. But certainty is not necessary. The goal is often to make some interpretations sufficiently more plausible than others. This gives us another way to think about privacy: the defender wants multiple interpretations of the same evidence to remain plausible; the analyst tries to eliminate or reweight those interpretations as more information becomes available.
A separate question is how these probabilistic inferences are treated outside research. We don’t need an omniscient observer to cause problems, a surprisingly small number of heuristics can go a long way. Chain-analysis evidence can carry significant weight in investigations and courtrooms, even when its methodology is not equivalent to mathematical proof. As these tools face increasing legal and methodological scrutiny, that gap between evidentiary usefulness and scientific certainty deserves its own discussion.
A separate question is how these inferences are treated outside research. An observer does not need anything close to perfect knowledge for blockchain analysis to have practical consequences. Clustering and attribution heuristics are used to generate investigative leads and can support search warrants, seizures, and ultimately evidence presented at trial. In the United States v. Sterlingov, for example, a federal court admitted expert testimony based on commercial blockchain-analysis software despite challenges concerning peer review and known error rates, and that decision was affirmed on appeal in 2026. That does not turn a heuristic attribution into mathematical certainty: evidentiary reliability and scientific certainty are different standards. Recent attempts to validate commercial attribution against ground-truth data have found encouraging accuracy alongside substantial variation in coverage, suggesting that the capabilities and limits of these tools deserve careful empirical study.
A few reasonably accurate heuristics, applied repeatedly over a large transaction graph, can go surprisingly far. Academic work has repeatedly demonstrated how clustering heuristics can be validated and extended using additional transaction structure and ground-truth data. Privacy therefore starts to look less like a binary property and more like a contest over inference. The attacker accumulates evidence and narrows the set of plausible explanations. The defender tries to keep more than one explanation alive.
Small choices leave long shadows
One particularly uncomfortable part of this process is wallet fingerprinting, for which we dedicated a whole working day. Wallets need to make many decisions when creating transactions: which coins to spend, how to order inputs and outputs, which sequence values to use, how to estimate fees, how signatures are encoded, how change is created, and many others.
Those choices are not always uniform across implementations. That means a transaction can carry evidence about the software that created it. We looked at examples where details as small as signature encoding or nSequence behavior could help separate inputs contributed by different wallets. More importantly, the analyst does not have to restrict the analysis to the transaction being studied. Previous and subsequent transactions provide additional observations of the same wallet's behavior. A fingerprint is therefore useful not only because it may identify a particular wallet. It can also eliminate candidate interpretations. If two inputs appear to have been produced by wallets with different behavioral fingerprints, that can provide evidence that they did not originate from the same actor even inside a collaborative transaction.
Recent analysis of real Payjoin transactions illustrates exactly this problem: wallet fingerprints that appear before, during, and after a collaborative transaction can sometimes help recover an ownership partition that the Payjoin was intended to obscure.
Privacy has a frustrating asymmetry. In cryptography, mathematics favors the defender whose main concern is to correctly implement the protocols. On the other hand, a privacy-enhancing protocol designer may need to eliminate many distinguishing signals, while an analyst only needs one sufficiently informative signal to narrow the set of plausible interpretations.
Breaking an assumption with Payjoin
Payjoin is appealing because the idea is so small. The common-input heuristic assumes that all inputs to a normal-looking transaction belong to one sender. So make that assumption false.
In a Payjoin transaction, both payer and receiver contribute inputs. A transaction produced this way is a genuine counterexample to common-input ownership: not every input belongs to the payer. The privacy question, however, is whether an analyst can recognize the transaction as collaborative, or recover the ownership partition using other information. BIP 78 specifies the original interactive protocol, while BIP 77 extends the design to asynchronous communication through a directory and uses Oblivious HTTP to reduce the network metadata exposed in that interaction.
We spent time not only on the transaction construction but also on the transport problem. That distinction matters. A privacy protocol that works beautifully on paper but requires users to operate unusual infrastructure or coordinate manually may never become common enough to matter.
BIP 77 tries to make Payjoin easier to deploy by introducing a directory through which sender and receiver can exchange encrypted messages asynchronously. At the same time, this introduces more infrastructure: directories, OHTTP gateways and relays. We left unconvinced about how quickly that ecosystem will become ubiquitous. The good news is that implementation work is progressing. Payjoin Dev Kit reached its first stable release shortly before our Deep Dive, and integration work with wallets is ongoing. We currently fund one fellow actively contributing to the project.
The more important lesson for us was conceptual. Payjoin really does break an important heuristic. That does not mean the transaction becomes private. If the two wallets behave differently enough, if the payment amount can be inferred, or if surrounding transactions reveal additional structure, the ambiguity can begin collapsing again. Payjoin therefore does not make chain analysis impossible. It changes the analyst’s task from applying an ownership assumption to deciding among competing ownership interpretations.
CoinJoin, and what WabiSabi actually buys
CoinJoin attacks the graph differently. Instead of two participants collaboratively constructing what resembles an ordinary payment, multiple users construct a transaction together so that the mapping between their inputs and outputs becomes ambiguous. This directly invalidates the simple assumption that every input of a transaction belongs to the same owner.
A powerful technique in the analyst’s toolbox is to try to split the Payjoin and CoinJoin transactions into subtransactions, a set of plausible smaller alternative payments that are semantically equivalent with respect to moving funds on-chain, but that can reveal the internal structure of the joined payments. We spent a considerable amount of time understanding the Boltzmann Transaction Entropy, a framework for reasoning about the ambiguity created by transaction amounts.
Even without assuming common input ownership, amounts constrain which subsets of inputs could plausibly fund which subsets of outputs. Boltzmann enumerates the transaction interpretations that remain compatible with those constraints and uses them to derive the linkability between individual inputs and outputs. This gave us a useful distinction. A transaction may invalidate common-input ownership and still reveal substantial structure through its amounts. Conversely, a transaction with many plausible interpretations may leave an analyst unable to confidently link a particular input to a particular output. The important question is therefore not simply whether a transaction is a CoinJoin, but how much of its ownership structure remains inferable from the information it exposes.
We then moved to WabiSabi, the protocol used to coordinate CoinJoins with arbitrary amounts. This was one of the more enjoyable parts of the Deep Dive because we went below the protocol diagram and into the cryptographic construction itself.
WabiSabi uses keyed-verification anonymous credentials together with homomorphic commitments to amounts. The coordinator can verify that participants are registering outputs funded by the value they previously registered without learning the specific relationship between those inputs and outputs. The amounts inside the credentials are represented using Pedersen commitments, and the required relationships are proven without opening them.
Understanding the protocol on paper is only part of the problem. Privacy guarantees also depend on implementation details, client behavior, coordinator behavior, coin selection, transaction construction, and whether clients actually enforce the assumptions the protocol relies on. Even a sound protocol-level construction does not settle the broader privacy problem.
CoinJoin can create ambiguity at one point in the transaction graph. What participants do before and after the CoinJoin still matters. A user who later spends several mixed outputs together can reveal that they had a common owner. Change can be mishandled. External information can link payments. And if several apparently independent post-mix transactions are later associated with the same person, the possible histories behind them can be intersected.
Ambiguity that looked substantial when each CoinJoin was considered independently can collapse much faster than intuition suggests. Research and subsequent analysis of cluster-intersection attacks make this point particularly stark: information revealed later can reach backward and weaken privacy obtained earlier.
Your privacy depends on other people
Payjoin and WabiSabi changed how we thought about the problem. More precisely, the anonymity visible locally in a CoinJoin transaction is not necessarily the anonymity that survives once later transactions and external information are considered. An anonymity set is not something you simply acquire once and keep. Later behavior can weaken it, and not necessarily only your own behavior.
This may have been the most discouraging conclusion of the week. Privacy-enhancing techniques such as Payjoin and CoinJoin create genuine ambiguity and break heuristics that analysts otherwise rely on. However, their effectiveness is fragile because Bitcoin transactions do not exist in isolation.
With Payjoin, the other participant's wallet behavior may reveal a fingerprint that helps separate the transaction again. With CoinJoin, the later behavior of participants can shrink the plausible set of histories. If some participants become identifiable, the remaining possibilities can change too. External data can be combined with blockchain data. Wallet implementations evolve. Each new piece of information can eliminate previously plausible explanations of an old transaction. This is why privacy on a public ledger has a temporal dimension: the anonymity of the past can depend on evidence that does not exist yet.
This leads to a stronger formulation of the privacy problem: privacy in Bitcoin is not a property of a transaction. It is an emergent property of a transaction graph, wallet behavior, counterparties, external information, and time. This is also why measuring privacy is difficult. Looking only at a CoinJoin transaction and counting equivalent outputs can give a useful local metric, but it cannot tell the entire story. The surrounding graph matters.
Fungi: trying to reason about the graph itself
That concern brought us to the Fungi Protocol, for which we also fund an active contributor as a fellow. We should be careful here: unlike WabiSabi, we did not finish the week with a complete mental model of the protocol. Part of the reason is simply that Fungi is still taking shape: much of the documentation we read lives in draft pull requests, with open questions, TODOs, and ideas that are still being refined.
What stood out to us was a collection of primitives and design directions that seemed interesting even before we could see the full picture. We looked at work around transaction interpretation, dense subset sum, privacy-aware coin selection, and coordination mechanisms for collaborative transactions. Some of these ideas seemed useful beyond Fungi itself, even if we were not yet able to understand how all of them fit together into a complete system.
One direction we found particularly interesting was the idea of moving beyond fixed transaction templates toward more general collaborative transactions and multiparty settlement, while making privacy considerations part of transaction construction itself.
Our understanding by the end of the week was therefore necessarily partial. Rather than leaving with a verdict on Fungi as a finished design, we came away with a set of ideas that pushed us to think more explicitly about privacy at the level of the transaction graph and about how wallets might incorporate privacy into their normal decision-making.
This direction also seemed promising for another reason: it could reduce how much privacy depends on users making the right decisions long after a collaborative transaction has been confirmed. If wallets continuously reason about the transaction graph when selecting coins and constructing transactions, preserving ambiguity becomes part of normal wallet behavior rather than something each participant has to remember and maintain manually.
The broader lesson is that privacy improves when safe behavior becomes ambient: when wallets automatically preserve ambiguity, and when ordinary activity itself provides plausible alternative explanations for what appears on-chain.
What would a wallet look like if privacy were part of its normal optimization function rather than a special operation the user occasionally invokes? And what would the blockchain look like if most wallets behaved that way?
Breaking the graph with CoinSwap
The protocol that produced the most immediate excitement in the room was CoinSwap, particularly the OpenSwap work implementing the Maxwell-Belcher design. The basic privacy idea is different from CoinJoin. Instead of creating one transaction in which many participants deliberately introduce ambiguity, CoinSwap lets parties atomically exchange control of coins so that the ownership history suggested by the transaction graph no longer necessarily corresponds to the economic history.
We followed the first version of the protocol in detail, including its cryptographic construction and failure paths, and came away convinced that the basic mechanism was sound. The newer construction can use Taproot and MuSig2 for contracts that look closer to ordinary Bitcoin spends. This matters because CoinSwap privacy depends not only on breaking ownership continuity, but also on making the swap itself difficult to identify from its on-chain footprint.
If a particular script pattern or transaction structure strongly suggests “this is a CoinSwap,” the analyst has already narrowed the hypothesis space considerably. If the same on-chain footprint could plausibly correspond to several unrelated protocols or economic activities, that first classification step becomes much harder.
This suggests another source of privacy: ordinary activity can provide cover. If a CoinSwap can be made indistinguishable from common Taproot interactions, Lightning liquidity management, submarine swaps, or other collaborative transactions, users performing those activities may enlarge the set of plausible explanations for the same on-chain footprint, even if they are not using CoinSwap for privacy at all.
OpenSwap is still under active development and explicitly does not recommend its current software for mainnet use. But the design was compelling.
What interested us most was not treating CoinSwap as a replacement for Payjoin or CoinJoin. Payjoin creates genuine exceptions to common-input ownership. CoinJoin creates competing mappings between participants’ inputs and outputs. CoinSwap can make visible transaction continuity diverge from economic ownership continuity. Taproot, MuSig2, multiparty signing, and other indistinguishability techniques can operate at yet another layer by making it harder to classify which protocol or economic activity produced a given on-chain footprint. Used together, and especially if they become common enough not to mark a user as exceptional, they can make the analyst's job substantially harder.
This felt like the right direction: not one perfect privacy protocol, but a transaction ecosystem in which fewer heuristics remain reliably applicable and more than one interpretation of the same on-chain evidence stays plausible.
Privacy cannot depend on expert users
There is, however, a serious problem with almost every privacy discussion in Bitcoin. Eventually someone gives the user a checklist:
- Do not reuse addresses.
- Do not consolidate these coins.
- Do not merge post-mix outputs.
- Treat this change as toxic.
- Use Tor here.
- Run this service.
- Wait for this round.
- Choose these coins but not those.
- Remember which history belongs to which UTXO.
This does not scale. If preserving privacy requires ordinary users to understand transaction graph analysis well enough to consistently defeat professional analysts, we have already lost. Coin selection should account for privacy automatically. Wallets should also reason about the transaction graph over time, so that preserving ambiguity does not depend on users remembering which future spends might undo privacy they gained many blocks earlier. Wallets should avoid unnecessary fingerprints. Collaborative transactions should happen when appropriate without turning every payment into a ceremony. Protocols should degrade gracefully when the other party does not support them.
Privacy-preserving behavior should increasingly become the normal behavior of Bitcoin wallets rather than a special mode used by the unusually motivated. This matters for another reason. Privacy loves company. And that company does not necessarily have to be using the same protocol for the same reason. Privacy can improve whenever ordinary economic activity produces the same observable patterns as privacy-seeking activity. The more ordinary privacy-preserving behavior becomes, and the more it blends into unrelated everyday activity, the less informative any particular on-chain pattern becomes.
Conversely, a technique used only by a small, easily identifiable population may give its users a very distinctive fingerprint even when the protocol itself provides strong internal privacy. A protocol can therefore succeed at hiding relationships among its participants while still making participation itself easy to classify.
We can’t expect every Bitcoin user to become an operational-security expert. The goal should be to build software that makes fewer privacy mistakes on their behalf.
Mixed feelings after five days
We ended this Deep Dive with two seemingly contradictory impressions. On one hand, blockchain analysis is hard. Trying to reconstruct economic activity from billions of transactions using imperfect heuristics is an enormous inference problem. Every heuristic has exceptions. Every cluster contains uncertainty. Collaborative transactions deliberately manufacture counterexamples to assumptions analysts would otherwise like to make.
The chain-analysis problem looked much less magical after studying it closely. There is no oracle that looks at the blockchain and reveals who owns what. There is evidence, inference, statistics, external information, and a lot of engineering.
That was reassuring.
On the other hand, leaking information is incredibly easy. A wallet implementation makes one unusual choice. Two coins are spent together. Change is handled carelessly. A mixed output later meets another mixed output. A counterparty uses different software. A payment amount appears elsewhere. A future transaction makes an old transaction easier to understand. The analyst does not need every clue to be correct or universally applicable. They only need enough of them to compound.
That was considerably less reassuring.
Five days at Casa21
There are outputs from a Deep Dive that eventually become visible: experiments, code, specification feedback, research questions, new projects, or simply a contributor who now understands a problem well enough to work on it.
But the immediate output is a better mental model.
For some of the less experienced developers in the room, there was another useful outcome: privacy refused to stay inside one abstraction layer of Bitcoin. Almost every paper and project we studied eventually forced us to cross boundaries. A discussion that began with transaction-graph heuristics would lead into wallet behavior and coin selection. Payjoin quickly became a question not only about transaction construction, but also networking and transport. WabiSabi took us from CoinJoin coordination into cryptographic commitments and anonymous credentials. CoinSwap required reasoning about scripts, Taproot, MuSig2, transaction structure, and the behavior of wallets before and after the swap.
That is a useful way to learn Bitcoin. The protocol is often taught as a collection of relatively separate subjects like cryptography, scripts, wallets, networking, consensus, but real problems rarely respect those divisions. Privacy made those interactions particularly visible. A decision that looks harmless at one layer can create a fingerprint at another; a cryptographically sound protocol can lose much of its value because of wallet behavior around it.
For newer contributors, seeing those connections is part of developing from someone who understands individual Bitcoin mechanisms into someone who can reason about the system as a whole. That’s a major educational goal we have for our fellowship program and a continuous effort of our grantees.
This week changed us. We started by asking how much privacy could exist on a public ledger. By Friday, the question felt different. The interesting battle is not between perfect anonymity and perfect surveillance. It is between ambiguity and inference.
Bitcoin exposes information because independent verification requires it. Our job as developers and researchers is to understand which additional conclusions observers are able to draw from that information, and then make those conclusions less reliable whenever we can. Payjoin does that. CoinJoin does that. CoinSwap does that. Better wallet behavior does that. None of them makes the problem disappear.
Perhaps that is the most important conclusion we took from the week: Bitcoin privacy will probably not come from one mechanism that finally “solves privacy.” It will come from systematically removing assumptions analysts are currently able to rely on, while making those protections ordinary enough that users do not need to understand the attacks they are being protected from.
And even this is only one layer of the problem. Other systems may further weaken the correspondence between what appears on the base-layer transaction graph and the underlying economic activity, from Lightning, Ark and statechains to client-side validation schemes, as well as more experimental constructions using BitVM, Pipes, zero-knowledge proofs, and related techniques. How much privacy these systems actually provide, and under which threat models, is a question for future Deep Dives.
Privacy is not a luxury feature for Bitcoin. It is part of making Bitcoin function as money. And if five days of trying to break privacy taught us anything, it is that there is still a great deal of work to do.