Cake Wallet Web: Payjoin Attack Surface – How Malicious Payjoin Servers Can Correlate Your Inputs to Outputs Despite Bitcoin’s Pseudonymity

Bitcoin’s blockchain is transparent by default. Every transaction shows inputs, outputs, and amounts in a public ledger. Payjoin (BIP-78) is a protocol designed to break one of the most useful chain analysis assumptions: that all inputs in a transaction belong to the same owner. By having a receiver contribute their own inputs to a payment, Payjoin scrambles that signal, making it harder for external observers to separate sender from receiver. But Payjoin’s privacy benefit depends entirely on the honesty and security of the Payjoin server that coordinates the exchange. A compromised or malicious server operator can see both the sender’s original inputs and the final transaction, creating a complete correlation map despite the protocol’s intended anonymity.

A user of a self-custody Bitcoin wallet like Cake Wallet Web might select Payjoin as a privacy enhancement, expecting that the transaction will look confused to third-party observers. What they may not fully understand is that they have introduced a new party—the Payjoin server—into the transaction creation process. That server, even if it implements the protocol correctly, sits in a position where it can correlate inputs and outputs with certainty. If the server is operated by someone with hostile intent or compromised by an attacker, the privacy improvement becomes an exposure. The recipient’s inputs become visible alongside the sender’s, and the flow of funds becomes transparent to whoever controls that infrastructure.

How Payjoin was designed to defeat chain analysis

Chain analysis relies on heuristics—probabilistic rules that usually work but are not absolute. The most powerful of these is the common input ownership heuristic: the assumption that if multiple inputs appear in the same transaction, they belong to the same wallet. This heuristic is not a certainty; it is merely what happens often enough to be useful. A transaction that consolidates several inputs usually means one owner is collecting their own funds before sending. But Payjoin violates this assumption by design. The sender constructs an initial transaction with their own inputs and outputs. The receiver then adds their own input to the same transaction, creating ambiguity about which inputs belonged to whom originally.

From the perspective of an external observer watching the blockchain, a Payjoin transaction looks unusual. Multiple inputs are present, but the logical ownership is scrambled. Chain analysis software that relies on the common input heuristic will be confused or, worse, will make an incorrect inference. This is the intended benefit. Payjoin also reduces the sender’s output visibility by having the receiver contribute an input; fewer large outputs leave fewer obvious change addresses for the receiver to analyze. The protocol is technically sound and requires active participation from both parties, making casual implementation mistakes less likely than with simpler privacy schemes.

However, Payjoin’s architecture creates a critical privacy vulnerability that the protocol itself does not and cannot fix: the Payjoin server must know the sender’s original unsigned transaction to coordinate the receiver’s inputs. The sender submits a preliminary transaction to the server, the server requests the receiver’s contribution, and then both parties sign the combined transaction. At every step, the Payjoin server sees exactly what inputs the sender provided and exactly which new inputs the receiver added. The server also knows the final transaction structure and outputs. This means the server can perform perfect input-output correlation without relying on blockchain analysis heuristics at all.

The Payjoin server as a central point of trust and failure

A Payjoin implementation requires a server because the protocol is interactive. The sender and receiver are often not online at the same moment, and they need a way to exchange transaction data without revealing identities through direct communication. A server acts as a coordinator: it receives the sender’s preliminary transaction, contacts the receiver (or receives a prepared response), combines the inputs, and facilitates the signing. This coordination is necessary, but it creates an unintended trust boundary.

When a sender uses cake wallet web or any non-custodial Bitcoin wallet with Payjoin enabled, they must choose or be assigned a Payjoin server. That choice is often invisible to the user. Some wallets default to a particular provider, others allow configuration, and some are hardcoded to a specific endpoint. Regardless of the mechanism, the server becomes an active participant in the transaction. It is not a passive observer like a blockchain node. The server sees the sender’s inputs in plaintext before any Payjoin mixing occurs, and it coordinates the receiver’s response.

If the Payjoin server is operated by an adversary, that operator has a complete view of the transaction flow. They know which inputs the sender controlled, which inputs the receiver controlled, and how the final amounts were distributed. They can correlate this information with other data they may have: IP addresses, timing metadata, payment requests, or information about wallets they monitor. A server operator could also log this data for future correlation with blockchain analysis, subpoena responses, or sale to third parties. The encryption and signing in the Payjoin protocol protects against external eavesdropping, but it provides no protection against the server itself.

Input correlation despite encryption and signing

Payjoin uses HTTPS and signed messages to prevent a network eavesdropper from observing the transaction details. This is important and correct. An adversary on the network path between the sender and the Payjoin server cannot see the preliminary transaction or intercept the receiver’s contribution. But this encryption solves a different threat model than server-side compromise. A malicious or compromised server operator is inside the trust boundary; encryption protects against outside attackers, not inside ones.

The attack is straightforward. The sender constructs a transaction with inputs from their wallet—say, three UTXOs totaling 2.5 BTC. The sender encrypts this transaction and sends it to the Payjoin server. The server decrypts it (because the protocol permits the server to do so for coordination purposes) and now knows exactly which three outputs the sender controls. The receiver adds one of their inputs, bringing the total to 2.7 BTC. The server again has cleartext visibility of the new input and can correlate it to the receiver. The final transaction is signed and published to the blockchain.

A third party observing only the final blockchain transaction sees 4 inputs (3 from the sender, 1 from the receiver) and multiple outputs. They cannot easily determine which inputs belonged to whom. But the Payjoin server has a complete map: sender inputs A, B, C; receiver input D; and the output structure. This is perfect correlation, unambiguous and absolute. The server does not need to guess, apply heuristics, or wait for on-chain evidence. It knows because it participated.

This problem has no easy fix at the protocol level because some party must coordinate the transaction. A peer-to-peer Payjoin without a server would require the sender and receiver to be online simultaneously and able to communicate directly, eliminating one of Payjoin’s practical benefits. Bitcoin protocol designs do not preclude Payjoin servers, but they also cannot force a server to be honest about what it observes. The trust in a Payjoin server is a social and operational choice, not a cryptographic guarantee.

How a compromised or hostile server amplifies the attack

A Payjoin server does not need to be obviously malicious to create risk. The most dangerous scenarios involve servers that appear legitimate but are either operated by an adversary from the beginning or compromised after deployment. A compromised server could have been maintained by a well-intentioned developer who had poor security practices, failed to update dependencies, or exposed credentials. An adversarial server might be operated by a blockchain analysis firm, a state actor, a regulatory agency, or a criminal organization seeking to deanonymize Bitcoin payments.

Once a Payjoin server operator has collected correlation data, they can apply it in several ways. They could cross-reference with IP addresses and timing data if the server logs this information. They could wait for the receiver to use their funds in a later transaction and observe where those funds go. They could combine the correlated data with other intelligence: wallet addresses observed in forums, social media, exchanges, or other services. The correlation data becomes particularly valuable when combined with heuristic analysis on the broader blockchain. If the receiver later consolidates the funds they received, that consolidation looks like a normal wallet operation, but the Payjoin server operator already knows which inputs were the receiver’s original ones.

A compromised server also introduces a secondary risk: the possibility of transaction tampering. A malicious server operator could subtly alter the final transaction to redirect a portion of the funds, although this would be detected during signing if both parties verify the transaction. A more insidious attack would be to log the transaction details and then, at a later time, use that information for targeted exploitation. For example, if the Payjoin server operator learns that a particular Bitcoin address received 5 BTC through Payjoin, they could target the owner of that address for theft, extortion, or regulatory enforcement.

Privacy wallet features that Payjoin does not address

Cake Wallet’s Bitcoin support includes other privacy tools alongside Payjoin: Silent Payments (BIP-352), UTXO coin control, transaction batching, and optional Tor integration. These tools work at different layers of privacy and address different threat models. Silent Payments allow a receiver to share a single static payment code instead of unique addresses, reducing address reuse and making received payments harder to link to a single identity. Coin control gives the sender explicit authority to choose which UTXOs to spend, preventing accidental consolidation of funds from different contexts. Tor obscures the IP address connecting to the Bitcoin network. None of these features prevent a Payjoin server from correlating inputs and outputs.

A user might reasonably ask whether using Silent Payments instead of Payjoin would be better. Silent Payments do not require a server and do not introduce a new trusted party. However, Silent Payments only address the receiver’s address privacy; they do nothing to break the common input ownership heuristic on the sender’s side. A transaction using Silent Payments may obscure which address a receiver provided, but the sender’s inputs remain linked to each other by blockchain analysis. Payjoin and Silent Payments solve different problems. Used together, they could offer more comprehensive privacy, but only if the Payjoin server is trustworthy—a condition that is difficult to verify and impossible to enforce.

Tor support, when enabled, prevents the Bitcoin network from learning the user’s IP address. This is valuable for network privacy but completely orthogonal to the correlation problem at the Payjoin server. A user could connect through Tor, use Payjoin, and still be correlated at the server level. The server may not know the user’s IP address, but it knows their inputs and outputs with certainty. Privacy at the network layer does not fix privacy problems at the protocol layer.

Verifying Payjoin server trustworthiness and selecting providers

Because Payjoin server operators have a privileged position, the choice of server matters enormously. A wallet user should understand where their chosen server is hosted, who operates it, what logs it keeps, how long those logs are retained, and what access policies exist. Unfortunately, most wallets do not make this information easily discoverable or configurable. Some wallets hardcode a default Payjoin server. Others use a provider list but do not clearly distinguish between public, community-operated, and commercial services.

An ideal Payjoin server would be operated by a party with no financial incentive to monetize transaction data, would delete request and response logs immediately, and would be auditable by independent security researchers. Such a server would be run by a non-profit, protocol developer, or privacy-focused entity. In practice, many Payjoin servers are operated by blockchain analysis companies, wallet providers, or services with unclear incentives. A user evaluating Payjoin should ask whether they know the server operator, whether they trust that operator, and whether they have any way to verify that logs are not being kept.

One partial defense is to run a personal Payjoin server and restrict its use to payments you initiate and receive. This creates no external correlation risk because you control both the sender and receiver sides of every transaction. However, this requires technical setup, ongoing maintenance, and defeats Payjoin’s intended purpose of allowing private transactions between arbitrary parties. For most users, running a personal server is impractical. For those users, trusting a public server is unavoidable, and the trust is both high-stakes and invisible.

Correlation risks in multi-receiver scenarios and change address leakage

Payjoin’s input-output confusion is most effective in simple scenarios: one sender, one receiver, one Payjoin server. But Bitcoin wallets often create transactions with multiple outputs, some of which are change addresses returned to the sender. A Payjoin server operator observing a transaction with multiple outputs can often infer which one is change and which one is the actual payment to the receiver, especially if one output is significantly larger than the other or has a round-number amount.

If the Payjoin server operator can identify the change output, they can deduce which outputs belong to the receiver, and therefore which inputs belonged to the sender originally. The common input ownership heuristic breaks down, but a simpler inference—amount matching—may work just as well. For example, if a sender wants to pay 1 BTC and their wallet holds 2.5 BTC, the output of 1.5 BTC is obviously change. The Payjoin server sees both sides of this calculation, making the identification trivial.

Bitcoin.org protocol documentation describes the address generation and change-handling mechanisms that wallets use, and these are generally transparent. A Payjoin server operator can apply the same reasoning. The protection that Payjoin offers against the common input ownership heuristic is therefore reduced if change outputs are discoverable. Some Payjoin implementations try to mitigate this by selecting change amounts that are not obvious multiples or by using multiple change outputs, but these are heuristic defenses against inference, not cryptographic protections against the server itself.

The broader lesson: infrastructure trust in privacy protocols

Payjoin is a well-designed protocol that solves a real problem in Bitcoin privacy. It genuinely confuses third-party chain analysis by obscuring the common input ownership heuristic. But its implementation exposes a class of privacy risk that purely cryptographic solutions do not: the risk that infrastructure operators have unprotected visibility into private transaction details. This is not unique to Payjoin. Similar issues arise with CoinJoin coordinators, Lightning Network channels, and any protocol that requires a server to coordinate transactions between parties.

The lesson for cryptocurrency users is that privacy cannot be reduced to a single protocol or feature. A transaction that is private against blockchain observers may not be private against infrastructure operators. A transaction that is private against infrastructure may not be private against timing analysis or counterparty identification. A payment that is private on the Bitcoin layer may leak information at the network layer through IP address or connection metadata. Privacy is a system property, not a label on a feature.

Users of Cake Wallet or any other self-custody Bitcoin wallet should understand which threat models their chosen privacy tools address. Payjoin addresses external chain analysis but introduces a new trusted party. Silent Payments reduce address reuse without introducing a server. Coin control prevents accidental linking of funds from different contexts. Tor protects IP addresses. Using all of these together provides defense in depth, but it also requires understanding what each tool does and what it does not.