CoinJoin vs PayJoin vs Silent Payments: Bitcoin Privacy
Compare Bitcoin privacy protocols CoinJoin, PayJoin, and Silent Payments across anonymity set, fees, and UX.
Bitcoin Privacy Protocols Compared
Bitcoin transactions are pseudonymous, not anonymous. Every payment leaves a permanent trace on a public ledger, and chain analysis firms have built sophisticated tooling to cluster addresses, identify senders, and deanonymize users. Three protocols have emerged as the primary defenses: CoinJoin, PayJoin, and Silent Payments. Each solves a different piece of the privacy puzzle.
CoinJoin breaks the link between transaction inputs and outputs through multi-party mixing. PayJoin defeats the common-input-ownership heuristic by having both sender and receiver contribute inputs to a payment. Silent Payments eliminate address reuse entirely by letting senders derive fresh one-time addresses from a single static key. The table below provides a high-level comparison.
| Property | CoinJoin | PayJoin | Silent Payments |
|---|---|---|---|
| Privacy type | Transaction graph obfuscation | Heuristic breaking | Address privacy (stealth addressing) |
| Anonymity set | 5 to 150+ per round | 2 (sender + receiver) | N/A (unique address per payment) |
| On-chain cost overhead | 2x to 10x a standard transaction | None (same size as regular payment) | None (standard Taproot output) |
| Coordinator fee | 0% to 0.3% (varies by coordinator) | None | None |
| Interactivity | All participants online simultaneously | v1: both online; v2: asynchronous | Non-interactive |
| Receiver action required | Yes (join the round) | Yes (contribute input) | No (just publish a static key) |
| Taproot compatible | Yes (Wasabi 2.x) | Yes | Native (uses P2TR outputs) |
| BIP | No formal BIP (protocol-level concept) | BIP 78 (v1), BIP 77 (v2) | BIP 352 |
For a broader view of Bitcoin's privacy landscape including on-chain analysis techniques and defense strategies, see our Bitcoin privacy landscape overview.
How CoinJoin Works
A CoinJoin transaction combines inputs from multiple independent users into a single transaction with equal-value outputs. Because every output is the same denomination, an observer cannot determine which input funded which output. The technique was first proposed by Gregory Maxwell in 2013 and has been the backbone of Bitcoin transaction privacy ever since.
The anonymity set of a CoinJoin round equals the number of equal-value outputs in the transaction. Wasabi Wallet's WabiSabi protocol supports variable output amounts with cryptographic blinding, producing rounds with 50 to 150 participants. JoinMarket uses a maker/taker model where market makers offer liquidity for a fee and takers initiate rounds, typically with 2 to 9 makers. The now-defunct Whirlpool protocol (Samourai Wallet) used fixed pools of 5 participants with free remixes across four denominations: 0.001, 0.01, 0.05, and 0.5 BTC.
The cost of CoinJoin is substantial. Each participant adds at least one input and one output to the transaction, making CoinJoins 2x to 10x larger than a standard payment in virtual bytes. Wasabi Wallet charges a 0.3% coordinator fee on inputs above 0.01 BTC (inputs at or below 0.01 BTC and remixes are free). JoinMarket maker fees are typically around 0.002%, making it cheaper but requiring more technical setup. At high fee rates, a single CoinJoin round can cost tens of thousands of sats in mining fees alone.
CoinJoin Wallet Landscape in 2026
The CoinJoin ecosystem has narrowed significantly. Samourai Wallet's founders were arrested in April 2024 and charged with money laundering and operating an unlicensed money transmitting business. Both pleaded guilty in July 2025 to conspiracy to operate an unlicensed money transmitting business. CEO Keonne Rodriguez was sentenced to five years and CTO William Lonergan Hill to four years in November 2025. Whirlpool's servers were seized and the service is permanently offline.
Wasabi Wallet remains the most accessible CoinJoin implementation. However, the default zkSNACKs coordinator suspended its CoinJoin coordination service on June 1, 2024, citing regulatory pressure following the Samourai arrests. Users must now connect to third-party coordinators (such as OpenCoordinator, which charges 0% coordinator fees). This reduces liquidity and can weaken anonymity sets if coordinator participation is low.
JoinMarket continues to operate as a fully decentralized alternative with no central coordinator. Its Jam GUI provides a more approachable interface, though compatibility issues with Bitcoin Core v30 (which removed BerkeleyDB wallet support) require users to run Bitcoin Core v29 or wait for descriptor wallet support in a future JoinMarket release.
How PayJoin Works
PayJoin (also called P2EP, or pay-to-endpoint) is a collaborative transaction where both sender and receiver contribute inputs. In a standard Bitcoin payment, all inputs belong to the sender. Chain analysis relies heavily on this assumption: the common-input-ownership heuristic assumes every input in a transaction is controlled by the same entity. PayJoin breaks this assumption by mixing the receiver's UTXOs into the transaction.
The result is a transaction that looks identical to a regular payment on-chain but poisons chain analysis models. If PayJoin adoption reaches even a small percentage of transactions, analysts can no longer confidently apply the common-input heuristic to any transaction, improving privacy for all Bitcoin users, not just PayJoin participants. The receiver also benefits from free UTXO consolidation, since their existing UTXOs are merged with the incoming payment.
PayJoin v1 (BIP 78) requires both sender and receiver to be online simultaneously via an HTTPS connection. This interactivity requirement limited adoption to merchant scenarios where a server could always be available. PayJoin v2 (BIP 77), authored by Dan Gould and Yuval Kogman, solves this by introducing an untrusted relay directory: the sender posts an encrypted proposal to the relay, and the receiver retrieves and signs it when they come online. All messages are end-to-end encrypted with HPKE, and Oblivious HTTP (OHTTP) prevents the relay from learning participant IP addresses. For a deeper technical analysis, see our PayJoin privacy research.
PayJoin Adoption Status
BTCPay Server supports both BIP 78 and BIP 77, making it the primary PayJoin receiver for merchants. Bull Bitcoin became the first mobile wallet to ship BIP 77 (PayJoin v2) send and receive capabilities in December 2024. Cake Wallet added PayJoin v2 support in May 2025, becoming the first mobile wallet to offer both Silent Payments and PayJoin v2 simultaneously. Sparrow Wallet and BlueWallet support PayJoin sends via BIP 78. The PayJoin Foundation, a 501(c)(3) nonprofit launched in August 2025 with funding from OpenSats, Cake Wallet, Spiral, and the Human Rights Foundation, sustains development of the Payjoin Dev Kit (PDK), a Rust library with bindings for Python, JavaScript, and Dart.
How Silent Payments Work
Silent Payments (BIP 352) use elliptic curve Diffie-Hellman (ECDH) to let a sender derive a unique one-time address for every payment from the receiver's single static public key. The receiver publishes one address (encoding a scan key and a spend key), and every sender who pays it generates a different on-chain output that only the receiver can detect and spend. No two payments share the same address, eliminating address reuse without requiring any interaction between sender and receiver.
This solves a fundamental UX problem: reusing addresses is a major privacy leak, but generating and distributing fresh addresses for every payment is impractical for donation pages, public profiles, and static QR codes. Silent Payments let a user post one address on their website and receive unlimited payments, each arriving at a distinct P2TR output invisible to anyone except the recipient. Unlike BIP 47 payment codes, Silent Payments require no on-chain notification transaction, eliminating both the fee overhead and the privacy leak that notification transactions introduce.
The tradeoff is scanning cost. To detect incoming payments, the receiver must perform an ECDH computation against every eligible transaction on the blockchain. For full nodes, this adds meaningful computational overhead during initial block download (estimated at 8 to 12 hours for a full scan on reference hardware). BIP 352 v1.1.0 (March 2026) introduced a per-group recipient limit of 2,323 (K_max) to mitigate quadratic scanning behavior for adversarial transactions. Light client scanning requires connecting to a specialized indexing server that provides per-block tweak data.
Silent Payments Wallet Support
BIP 352 reached "Complete" status (v1.1.1) as of mid-2026. The critical secp256k1 cryptographic module for Silent Payments was merged in June 2026, but wallet-level send and receive PRs for Bitcoin Core remain open and have not shipped in any released version yet. Companion BIPs extend the ecosystem: BIP 375 and BIP 376 define PSBT fields for Silent Payment tweak data (enabling hardware wallet compatibility via DLEQ proofs), and BIP 392 introduces a descriptor format for output descriptors. On the wallet side, Cake Wallet was among the first mobile wallets to ship Silent Payments on both iOS and Android (v4.18.0, May 2024). Sparrow Wallet supports both sending (v2.3.0) and receiving (v2.5.0) but requires a compatible Electrum server for scanning. Silentium is a purpose-built mobile wallet focused entirely on BIP 352, using an index server backend for efficient light client scanning. BlueWallet and Wasabi Wallet support sending to Silent Payment addresses, while BitBox02 became the first hardware wallet to sign Silent Payment transactions.
Technical Comparison
The following table compares each protocol across dimensions that matter most to developers and power users evaluating privacy tooling.
| Dimension | CoinJoin | PayJoin (BIP 77/78) | Silent Payments (BIP 352) |
|---|---|---|---|
| What it hides | Input-output links (transaction graph) | Input ownership (breaks clustering) | Receiver address linkability |
| Transaction size | Large (many inputs/outputs) | Same as normal payment | Same as normal payment |
| Distinguishable on-chain | Yes (equal-value outputs are a fingerprint) | No (looks like a regular transaction) | No (standard P2TR output) |
| Requires special software | Sender and all participants | Sender and receiver | Sender only (receiver scans) |
| Coordinator or relay | Coordinator required (centralized or market) | v1: receiver server; v2: untrusted relay | None |
| Minimum participants | 2+ (meaningful privacy at 5+) | 2 (sender + receiver) | 1 (sender pays, no coordination) |
| Chain analysis resistance | Strong (with high anonymity set and multiple rounds) | Moderate (poisons heuristics, no mixing) | Strong (no address linkability) |
| Receiver computation | Minimal | Minimal | High (ECDH scan per transaction) |
| Light client friendly | Yes | Yes | No (requires full scan or index server) |
| Primary implementations | Wasabi (WabiSabi), JoinMarket (Jam) | BTCPay Server, Bull Bitcoin, Cake Wallet | Cake Wallet, Sparrow, Silentium |
Complementary Privacy: Address Privacy vs Transaction Privacy
These three protocols are not competitors: they solve different layers of the privacy problem and are most effective when used together.
Silent Payments provide address privacy. A receiver can accept payments without ever revealing that two payments went to the same person. But once funds arrive, their on-chain history remains visible. If a sender funds the payment from a known exchange withdrawal, the receiver's UTXO still carries that taint.
CoinJoin provides transaction-graph privacy. It severs the link between a UTXO's history and its current owner. After a CoinJoin round, chain analysis can no longer trace where the coins came from. But CoinJoin does nothing about address reuse: if you receive multiple payments to the same address and then CoinJoin them, the address clustering has already happened.
PayJoin provides heuristic-breaking privacy. It does not create an anonymity set or hide addresses, but it undermines the assumptions that chain analysis depends on. When PayJoin transactions are indistinguishable from regular payments, the reliability of automated clustering drops across the entire network.
The ideal privacy workflow combines all three: receive via Silent Payments (address privacy), optionally CoinJoin the received UTXOs (transaction-graph privacy), and spend via PayJoin (heuristic breaking). Each layer closes gaps the others leave open.
Privacy Beyond Layer 1
On-chain privacy protocols face inherent constraints: every transaction is permanently recorded on a public ledger, and each privacy technique adds complexity, cost, or computational overhead. Layer 2 protocols offer a different approach by moving transactions off-chain entirely.
The Lightning Network routes payments through encrypted onion-routed channels, hiding payment details from intermediate nodes. However, channel opens and closes are visible on-chain, and routing nodes can observe payment amounts. Spark takes a different approach as a Bitcoin Layer 2: transfers happen as ownership changes within a FROST threshold signature scheme, leaving no on-chain footprint for individual transfers. This means Spark transactions are not visible to blockchain surveillance at all, providing privacy characteristics that complement the on-chain techniques described above.
For users who want both on-chain and off-chain privacy, a practical approach is to receive via Silent Payments on Layer 1, move funds to Spark or Lightning for day-to-day spending, and use CoinJoin or PayJoin when settling back on-chain. See our Bitcoin privacy tools comparison for a broader survey of available options.
Regulatory and Legal Considerations
The legal landscape for Bitcoin privacy tools has shifted significantly. The April 2024 arrest and subsequent sentencing of Samourai Wallet's founders established precedent that operating a CoinJoin coordination service can be prosecuted as unlicensed money transmission. Wasabi Wallet's zkSNACKs coordinator shut down voluntarily the same year.
PayJoin and Silent Payments occupy a different regulatory position. Neither involves a coordinator, mixing service, or pooled funds. PayJoin produces transactions that are structurally identical to regular Bitcoin payments. Silent Payments are indistinguishable from standard P2TR transactions on-chain. Both are implemented directly in the Bitcoin protocol stack without intermediary services, making them harder to characterize as money transmission.
No jurisdiction has prosecuted individual users for using CoinJoin for personal privacy. The legal risk has been concentrated on service operators, not end users. However, the regulatory environment continues to evolve, and KYC/AML requirements increasingly affect how exchanges treat coins with CoinJoin history.
Frequently Asked Questions
What is the difference between CoinJoin and PayJoin?
CoinJoin mixes coins from multiple unrelated parties into a single transaction with equal-value outputs, creating an anonymity set that prevents observers from linking inputs to outputs. PayJoin is a two-party protocol where sender and receiver both contribute inputs to a payment, making the transaction look normal on-chain while breaking the common-input-ownership heuristic that chain analysis relies on. CoinJoin costs more in fees and is visually identifiable on-chain; PayJoin has zero overhead and is indistinguishable from a regular transaction.
Are Silent Payments the same as stealth addresses?
Silent Payments are a specific implementation of the stealth address concept adapted for Bitcoin. Earlier stealth address proposals (such as BIP 47 payment codes) required an on-chain notification transaction before payments could begin, introducing both fee overhead and a privacy leak. BIP 352 Silent Payments eliminate this setup step entirely: the sender derives a unique address directly from the receiver's public key using ECDH, with no prior on-chain interaction needed. The tradeoff is that receivers must scan all transactions to detect payments, which is computationally expensive.
Which Bitcoin privacy method is best?
No single method provides complete privacy. CoinJoin is strongest for breaking transaction history (especially with multiple rounds and anonymity sets above 50), but it is expensive and leaves a visible CoinJoin fingerprint. PayJoin is free and invisible on-chain but only involves two parties and requires sender-receiver coordination. Silent Payments solve address reuse without any interaction but add scanning overhead for receivers. The most effective approach combines all three: receive via Silent Payments, CoinJoin when needed, and spend via PayJoin.
Do I need a full node to use Silent Payments?
A full node provides the best experience because Silent Payments scanning requires checking every eligible transaction against your keys. However, several wallets support Silent Payments without requiring users to run a full node. Cake Wallet handles scanning on mobile, and Sparrow Wallet connects to a compatible Electrum server for indexing. Silentium uses a purpose-built index server that provides tweak data without learning which outputs belong to the user. Light client infrastructure is still maturing, with approaches like Frigate and BlindBit Oracle offering different privacy and bandwidth tradeoffs.
Is CoinJoin legal?
Using CoinJoin for personal transaction privacy has not been prosecuted in any jurisdiction. The legal actions in 2024 and 2025 targeted the operators of CoinJoin coordination services: Samourai Wallet's founders were convicted of conspiracy to operate an unlicensed money transmitting business, and zkSNACKs voluntarily shut down its Wasabi Wallet coordinator. However, many exchanges flag or reject deposits with CoinJoin history, which can create practical friction. The legal distinction between operating a mixing service and using one as an individual remains an area of active legal development.
Can PayJoin scale to improve privacy for all Bitcoin users?
Yes, and this is PayJoin's most powerful property. Unlike CoinJoin, which only benefits participants, PayJoin creates a positive externality for the entire network. If even a small percentage of Bitcoin transactions use PayJoin, the common-input-ownership heuristic becomes unreliable for all transactions, since analysts cannot distinguish PayJoin transactions from regular ones. PayJoin v2 (BIP 77) and the Payjoin Dev Kit lower the integration barrier for wallet developers, and research into multi-party PayJoin ("PayJoin v3") aims to extend the protocol beyond two-party transactions.
How does Spark handle privacy compared to on-chain methods?
Spark operates as a Bitcoin Layer 2 where transfers are ownership changes within a distributed operator set using FROST threshold signatures. Individual Spark transfers do not appear on the Bitcoin blockchain, so they are invisible to chain analysis tools entirely. This is fundamentally different from on-chain privacy techniques like CoinJoin (which still produces a visible, albeit obfuscated, transaction) or Silent Payments (which produce standard on-chain outputs). The tradeoff is that Spark's operators can observe transfer metadata, though the operator set is distributed across independent entities.
This tool is for informational purposes only and does not constitute financial or legal advice. Privacy protocol capabilities, wallet support, and regulatory status change frequently. Always verify current implementations and consult legal counsel regarding privacy tool usage in your jurisdiction.
Build with Spark
Integrate bitcoin, Lightning, and stablecoins into your app with a few lines of code.
Read the docs →
