PayJoin: Breaking Transaction Analysis with Collaborative Transactions

Every Bitcoin transaction leaves a trace on a public ledger. Chain surveillance firms exploit predictable transaction patterns to cluster addresses, trace fund flows, and deanonymize users. The single most powerful assumption they rely on is simple: all inputs in a transaction belong to the same person. PayJoin breaks that assumption by having both sender and receiver contribute inputs to a single transaction, making it indistinguishable from ordinary payments.

Formalized in BIP 78, PayJoin (also known as P2EP or pay-to-endpoint) is a collaborative transaction protocol that poisons the datasets of blockchain analysts. Unlike mixing protocols that require large anonymity sets and special-purpose transactions, PayJoin disguises itself as a normal payment. This article covers how the protocol works, why it matters for Bitcoin privacy, and where it fits alongside other privacy techniques.

The Common-Input-Ownership Heuristic

Bitcoin's UTXO model means that wallets often combine multiple unspent outputs as inputs to fund a single payment. When a transaction contains three inputs, chain analysis software assumes all three belong to the same entity. This is the common-input-ownership heuristic (CIOH), first described in Satoshi Nakamoto's original whitepaper as a privacy risk and later formalized by Meiklejohn et al. in their 2013 study of Bitcoin transaction graph analysis.

The heuristic is powerful because it is almost always correct in standard transactions. A wallet selecting coins from its own pool will naturally produce transactions where every input shares the same owner. Surveillance firms chain this assumption across thousands of transactions to build address clusters, linking pseudonymous addresses to real-world identities through exchange deposits, merchant payments, and other touchpoints.

Why this matters: The common-input-ownership heuristic is the foundation of nearly all commercial blockchain surveillance. If it becomes unreliable, the entire clustering methodology breaks down: not just for PayJoin transactions, but for every transaction in the analyst's dataset, since they can no longer be confident which transactions are collaborative and which are not.

How clustering works in practice

Consider a transaction with inputs from addresses A1, A2, and A3 paying to address B1 with change returning to A4. A chain analyst concludes that A1, A2, A3, and A4 all belong to the same wallet. If A1 was previously used to withdraw from a KYC exchange, the analyst now links all four addresses to that identity. Repeat this across every transaction the wallet makes, and you build a complete financial profile.

This technique underpins tools from firms like Chainalysis, Elliptic, and CipherTrace. It works so well that it has become the default assumption baked into law enforcement investigations, compliance screening, and tax reporting. PayJoin targets this assumption directly.

How PayJoin Works

In a standard Bitcoin payment, only the sender provides inputs. The receiver simply supplies a destination address. PayJoin changes this: both the sender and receiver contribute inputs to the transaction. The result is a single transaction that looks ordinary on the blockchain but violates the common-input-ownership assumption.

A simple example

Alice wants to pay Bob 0.5 BTC. In a normal transaction, Alice selects one or more of her UTXOs as inputs, creates an output paying Bob 0.5 BTC, and returns change to herself. In a PayJoin transaction, Bob also contributes one of his own UTXOs as an input. The transaction might look like this:

An analyst looking at this transaction sees two inputs and two outputs. Applying the common-input-ownership heuristic, they assume both inputs belong to the same person and conclude the transaction is a simple payment of 0.8 BTC (or 0.3 BTC) with change. They get the payment amount wrong, they cluster the wrong addresses together, and their entire analysis is poisoned.

Why it looks normal

PayJoin transactions have no distinguishing on-chain fingerprint. They use standard transaction types, standard SegWit input scripts, and produce outputs that match typical payment patterns. There is no special opcode, no unusual output count, and no telltale equal output amounts (as with some CoinJoin implementations). This is the key insight: privacy through indistinguishability from normal transactions.

The BIP 78 Protocol

BIP 78 specifies the PayJoin protocol. It builds on PSBTs (Partially Signed Bitcoin Transactions, defined in BIP 174) to enable sender and receiver to collaboratively construct a transaction. The protocol works as follows:

1. The receiver generates a BIP 21 URI containing a standard Bitcoin address plus a PayJoin endpoint URL (the pj= parameter).
2. The sender's wallet detects the PayJoin endpoint and constructs a preliminary transaction (the "original PSBT") that pays the receiver normally, as if PayJoin were not being used.
3. The sender transmits this original PSBT to the receiver's PayJoin endpoint over HTTPS.
4. The receiver validates the original PSBT, then modifies it: adding one or more of their own inputs, adjusting outputs as needed, and returning the modified PSBT (the "payjoin proposal") to the sender.
5. The sender validates the proposal to ensure the receiver has not tampered with the payment amount or introduced unexpected changes. The sender then signs their inputs and broadcasts the final transaction.

Fallback guarantee: If the PayJoin negotiation fails at any step (the receiver's server is down, the proposal is invalid, or the sender rejects the modifications), the sender's wallet simply broadcasts the original transaction. PayJoin is a strict upgrade: it never prevents a payment from completing.

Security properties of BIP 78

The protocol includes several protections for the sender:

• The receiver cannot increase the payment amount beyond what the sender originally agreed to pay.
• The sender verifies that their own inputs and the payment output remain intact in the proposal.
• The receiver's added inputs must use the same script type as the sender's inputs to avoid creating a distinguishing fingerprint.
• The sender checks that the transaction fee has not been unreasonably increased.

These checks ensure that even a malicious receiver cannot steal funds through the PayJoin protocol. The worst outcome is that PayJoin negotiation fails and the payment proceeds normally.

PayJoin version 2: serverless PayJoin

The original BIP 78 requires the receiver to run an HTTPS server, which limits adoption to merchants and services with web infrastructure. The PayJoin v2 proposal (based on work by Dan Gould) removes this requirement by introducing a relay-based architecture. Sender and receiver communicate through an untrusted relay server using encrypted, authenticated messages. The relay cannot read the transaction contents or modify the protocol messages.

PayJoin v2 also supports asynchronous operation: the sender and receiver do not need to be online simultaneously. The sender posts their original PSBT to the relay, and the receiver retrieves it, constructs the proposal, and posts it back. This makes PayJoin viable for mobile wallets and peer-to-peer payments where both parties are not always online.

PayJoin vs CoinJoin

Bitcoin's scripting system supports multiple privacy-enhancing transaction types. CoinJoin and PayJoin both involve multiple parties contributing inputs to a single transaction, but they differ fundamentally in design philosophy, privacy model, and practical tradeoffs.

CoinJoin overview

CoinJoin, originally proposed by Gregory Maxwell, batches inputs from many unrelated users into a single transaction with equal-value outputs. The uniform output amounts make it impossible to link specific inputs to specific outputs. Implementations like Wasabi Wallet (using the WabiSabi protocol) and JoinMarket coordinate these multi-party transactions with varying degrees of centralization.

Key differences

Complementary approaches

PayJoin and CoinJoin are not mutually exclusive. A user might CoinJoin their funds to break existing transaction history, then use PayJoin for subsequent payments to prevent new clustering. The techniques target different parts of the privacy problem: CoinJoin obscures the link between past and present, while PayJoin prevents new links from forming during ordinary spending.

Privacy Implications at Scale

PayJoin's privacy benefit is not limited to the participants in a given PayJoin transaction. Every PayJoin transaction that occurs on the network creates uncertainty about every other transaction. If even a small percentage of Bitcoin transactions are PayJoins, analysts can no longer trust the common-input-ownership heuristic for any transaction, because they cannot distinguish which ones are PayJoins and which are not.

This property is sometimes called "steganographic privacy": the privacy-enhancing transactions hide within the set of all normal transactions, rather than standing out as special transactions (as CoinJoins do with their equal outputs). The more PayJoin transactions that exist, the weaker the CIOH becomes across the entire network.

The probing problem

On the Lightning Network, privacy concerns manifest differently. Network participants can use probing to discover channel balances and trace payment paths. On-chain, the equivalent surveillance technique is UTXO clustering via the CIOH. PayJoin addresses the on-chain threat, while Lightning privacy improvements (such as onion routing and blinded paths) address the off-chain threat.

Adoption Challenges

Despite its elegant design, PayJoin adoption has been slow. Several practical obstacles have limited its deployment:

• Receiver infrastructure: BIP 78 requires the receiver to run an HTTPS endpoint. Most Bitcoin users, and even many merchants, do not operate web servers capable of handling PayJoin requests.
• Wallet support: both the sender and receiver wallets must support the PayJoin protocol. Adoption requires coordination across the ecosystem.
• Interactivity requirement: unlike a standard Bitcoin payment where the receiver simply provides an address, PayJoin requires real-time communication between sender and receiver during transaction construction.
• Input availability: the receiver needs at least one confirmed UTXO to contribute as an input. A receiver with only unconfirmed or zero-balance funds cannot participate.
• Education: many users and merchants are unaware that PayJoin exists or do not understand why it matters for their privacy.

PayJoin v2's relay-based design addresses several of these issues, particularly the server requirement and the need for simultaneous online presence. But wallet-level adoption remains the primary bottleneck.

Implementations and Wallet Support

Several projects have implemented or are actively developing PayJoin support:

Current implementations

BTCPay Server deserves particular attention as the most widely deployed PayJoin receiver. Any merchant running BTCPay Server can accept PayJoin payments automatically, and the software handles all the PSBT construction and validation. This means the existing network of BTCPay merchants already forms a PayJoin-capable payment infrastructure.

PayJoin and UTXO Management

Beyond privacy, PayJoin provides a practical benefit for UTXO management. The receiver can use PayJoin to consolidate small UTXOs by including them as inputs in payment transactions. This consolidation happens during a real payment, so it costs no additional fees: the receiver effectively gets free UTXO consolidation as a side effect of receiving a payment.

For merchants who receive many small payments, this is especially valuable. Without PayJoin, a merchant accumulates hundreds of small UTXOs and must eventually consolidate them in a separate transaction, paying fees and revealing their total balance to chain observers. With PayJoin, consolidation happens incrementally and privately.

Relationship to Other Privacy Techniques

PayJoin exists within a broader ecosystem of Bitcoin privacy tools. Understanding how these techniques relate helps users choose the right approach:

• Schnorr signatures and Taproot improve on-chain privacy by making multisig transactions look identical to single-sig transactions, reducing the fingerprinting surface for all transaction types including PayJoin.
• Onion routing on Lightning protects payment path privacy for off-chain transactions, complementing PayJoin's on-chain privacy improvements.
• Replace-by-fee can interact with PayJoin: a sender who broadcasts the original (non-PayJoin) transaction could have it replaced by the PayJoin version if both are in the mempool, though proper implementations avoid this scenario.
• MuSig2 enables key aggregation that can further reduce the on-chain footprint of collaborative transactions.

Off-Chain Alternatives: Spark and Layer 2 Privacy

PayJoin improves privacy for on-chain transactions, but on-chain transactions are inherently public. Spark takes a fundamentally different approach: transactions happen entirely off-chain. When Alice sends Bitcoin to Bob on Spark, no public record of the transfer is created. The transfer involves a cryptographic key rotation between participants and Spark operators, with no blockchain transaction required.

This means Spark transactions do not produce the UTXO graph that chain surveillance relies on. There are no inputs to cluster, no change outputs to analyze, and no transaction graph to traverse. The privacy model is structural rather than obfuscatory: the data simply does not exist on a public ledger.

When Spark does settle to the Bitcoin base layer (for deposits or withdrawals), the on-chain transactions could potentially be constructed as PayJoin transactions, combining the off-chain privacy of Spark with on-chain heuristic-breaking for settlement. This layered approach addresses privacy at multiple levels of the stack.

Future Directions

Several developments could accelerate PayJoin adoption:

• PayJoin v2 relay infrastructure: as public relays become available, mobile wallets can support PayJoin without running servers.
• Wallet descriptor integration: wallets that adopt Miniscript and output descriptors can more easily implement the PSBT manipulation that PayJoin requires.
• Taproot adoption: as more wallets migrate to Taproot outputs, PayJoin transactions become even more indistinguishable because Taproot makes all spend conditions look identical on-chain.
• Payment protocol standardization: efforts to integrate PayJoin into BOLT 12-style payment flows could bring PayJoin concepts to Lightning-compatible invoicing systems.

Conclusion

PayJoin is one of the most underappreciated privacy tools in Bitcoin. By breaking the common-input-ownership heuristic with transactions that are indistinguishable from normal payments, it undermines the foundational assumption of blockchain surveillance. Unlike mixing protocols that create identifiable on-chain patterns, PayJoin hides in plain sight.

The protocol's adoption challenges are real: interactivity requirements, wallet support, and receiver infrastructure have all slowed deployment. But PayJoin v2's relay-based architecture addresses the most significant barriers, and BTCPay Server's implementation provides a growing base of PayJoin-capable receivers.

For users who transact on-chain, PayJoin represents an immediate, practical improvement to financial privacy. For the broader ecosystem, even modest adoption rates weaken chain analysis across all transactions. And for those using Layer 2 solutions like Spark, PayJoin can complement off-chain privacy with improved settlement transactions, creating a multi-layered approach to financial privacy on Bitcoin.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.