The Evolution of Bitcoin Privacy: From CoinJoin to Silent Payments

Bitcoin’s blockchain is transparent by design. Every transaction, every address, every satoshi movement is visible to anyone with an internet connection. For sound money, this transparency is a feature. For personal privacy, it’s a problem.

Over the past decade, developers have built increasingly sophisticated privacy techniques to solve this problem without compromising Bitcoin’s core properties. Three approaches stand out: CoinJoin (break the transaction graph), PayJoin (poison the heuristics), and Silent Payments (eliminate address reuse). Each solves different problems. Each has different trade-offs.

Here’s how they work, when to use them, and where the ecosystem stands in 2026.

CoinJoin: breaking the common input heuristic

CoinJoin is the oldest and most battle-tested privacy technique in Bitcoin. The core idea is simple: if multiple people combine their transactions into one, outside observers can’t tell who paid whom.

How it works

Blockchain surveillance relies on heuristics. The biggest one: all inputs in a transaction belong to the same person. This assumption holds most of the time, which makes it powerful for clustering addresses and tracking funds.

CoinJoin breaks this assumption by having multiple users create a collaborative transaction. If Alice wants to send herself 1 BTC and Bob wants to send himself 1 BTC, they create one transaction with both inputs and both outputs. An observer sees the transaction but can’t determine which input funded which output.

Two main approaches have emerged:

Wasabi Wallet (zkSNACKs protocol): Uses a coordinator server to organize CoinJoin rounds. Participants register their inputs, the coordinator creates an unsigned transaction template, and participants sign via Tor to prevent linking. The original zkSNACKs coordinator shut down in June 2024, but the protocol continues through community-run coordinators.

Whirlpool (Samourai/Ashigaru): Takes a different approach with equal-output pools and many smaller mixing cycles instead of one large round. The coordinator is blinded (can’t see message contents), and the protocol aims for 100% entropy between inputs and outputs. After Samourai’s legal troubles in April 2024, the project was forked as Ashigaru and continues development.

The trade-offs

CoinJoin works, but it’s not subtle. CoinJoin transactions are identifiable on-chain. Equal outputs, multiple participants, distinctive patterns. You can see that privacy techniques were used, even if you can’t see through them.

This creates a secondary problem: some exchanges and services flag CoinJoin outputs as “tainted.” I think this narrative is mostly FUD (the point is breaking UTXO links, not hiding that you used privacy tools), but it’s a real friction point for users.

The benefits are clear: immediate privacy gain, proven technique since 2013, effective against blockchain surveillance. But you pay for it with coordination overhead, higher fees, and on-chain visibility.

Best for: Users who want to break their UTXO history and don’t mind that it’s visible they did so.

PayJoin: the invisible privacy tool

PayJoin is the most underrated privacy technique in Bitcoin. While everyone focuses on CoinJoin and Silent Payments, PayJoin quietly does something remarkable: it makes blockchain surveillance actively misleading.

How it works

PayJoin (also called P2EP, specified in BIP-78) is a collaborative transaction between sender and receiver during a payment. The magic is that it looks exactly like a normal Bitcoin transaction.

Here’s the flow:

1. Receiver generates a payment request (BIP21 URI) with a pj= parameter pointing to their PayJoin endpoint
2. Sender creates a signed transaction (PSBT) and sends it to the receiver’s endpoint
3. Receiver adds their own inputs to the transaction, adjusts outputs if desired, and returns the modified PSBT
4. Sender verifies the proposal, re-signs, and broadcasts

The result is a transaction that breaks multiple blockchain analysis heuristics:

Common input ownership: The transaction now has inputs from both sender and receiver. Surveillance algorithms assume all inputs belong to one person. They’re wrong.

Change identification: Receiver can adjust output types to match the sender’s change pattern, misleading change detection algorithms.

Amount analysis: Receiver can add decoy outputs with round amounts, breaking payment amount heuristics.

Why PayJoin matters more than you think

Here’s what makes PayJoin special: it doesn’t just provide privacy for users who adopt it. It poisons the heuristics for everyone.

If 10% of transactions are PayJoin, blockchain surveillance can’t trust the common input heuristic for any transaction. The uncertainty spreads. Privacy becomes a public good.

The downside? Both sender and receiver must support BIP-78. The receiver needs to be online or use a payment processor. Adoption is limited: BTCPay Server, Wasabi, JoinMarket, BlueWallet (in progress). But for merchant payments and donations, it provides “free” privacy during the natural payment flow.

Best for: Any scenario where both parties can coordinate. The privacy is a bonus on top of the payment you were making anyway.

Silent Payments: static addresses without interaction

Silent Payments solve a different problem: how do you accept multiple payments without reusing addresses or requiring sender-receiver interaction?

The problem

Bitcoin’s privacy model assumes you generate a new address for every payment. This works fine when you can interact with the sender (send them an invoice, generate a new address). But what about donation buttons? Social media bio links? Any scenario where you want a static payment identifier?

Before Silent Payments, your options were bad:

• Reuse addresses (links all payments publicly)
• Use BIP-47 PayNyms (requires on-chain notification transaction)
• Run a server to generate addresses on demand (centralization, complexity)

Silent Payments (BIP-352, merged May 2024) use clever cryptography to solve this without interaction or on-chain overhead.

How it works

A Silent Payment address contains two public keys: a scan key (B_scan) and a spend key (B_spend).

When someone sends you a payment:

1. They collect all their input public keys and sum them: A = A₁ + A₂ + … + Aₙ
2. They compute a shared secret using Elliptic Curve Diffie-Hellman: shared_secret = input_hash × a × B_scan
3. They derive a unique output: P = B_spend + hash(shared_secret || k) × G
4. They create a normal taproot output to this address

To receive:

1. You scan the blockchain for eligible transactions (anything with taproot outputs)
2. For each transaction, you compute the shared secret: shared_secret = input_hash × b_scan × A
3. You check if any taproot outputs match: P = B_spend + hash(shared_secret || k) × G
4. If there’s a match, you can spend it with: private_key = b_spend + hash(shared_secret || k)

The beauty: sender and receiver independently derive the same shared secret using ECDH. No communication needed. No on-chain coordination. Just math.

The scanning trade-off

Silent Payments’ superpower is also its weakness: scanning.

To detect payments, you need to check every eligible transaction on the blockchain. For a full node, this is trivial (one elliptic curve multiplication per transaction). For a light client, it’s a challenge.

Current estimates (as of 2024 data): 30-50 MB per month with today’s taproot adoption, potentially 450 MB per month if Bitcoin goes 100% taproot. Transaction cut-through (skipping spent outputs) can reduce this by 75%, but it’s still significant for mobile wallets.

The benefits are compelling: no sender-receiver interaction, no on-chain overhead, no address reuse, no blockchain spam. Every payment creates a unique address that looks like a normal taproot output. Perfect forward secrecy.

Best for: Donation addresses, public tipping, recurring payments from multiple senders where interaction is impractical. Optimized for users running full nodes.

Choosing the right tool

These techniques solve different problems. Here’s when to use each:

Feature	CoinJoin	PayJoin	Silent Payments
Privacy model	Breaks input clustering	Poisons heuristics	Prevents address reuse
Interaction required	Coordinator + participants	Sender + receiver	None
On-chain visibility	Identifiable (equal outputs)	Looks normal	Looks normal (taproot)
Sender overhead	Coordination wait, fees	HTTP request	Standard tx + ECDH
Receiver overhead	None (if not participating)	Endpoint + PSBT handling	Blockchain scanning
Light client support	Standard	Standard	Challenging (30-450 MB/mo)
When to use	Break UTXO history	During payment	Static address needed

The key insight: these aren’t competing solutions. They’re complementary tools for different scenarios:

• Use CoinJoin when you want to break the link between your current UTXOs and their history
• Use PayJoin when making a payment to someone who supports it (the privacy is free)
• Use Silent Payments when you need a static receiving address without address reuse

You can combine them. CoinJoin your coins, then use PayJoin for a merchant payment, and publish a Silent Payment address for donations. Each adds a different layer of privacy.

Silent Payments in 2026: current state

Silent Payments are still early, but infrastructure is maturing fast.

Wallet adoption

Sending support:

• Cake Wallet implemented support in early 2024, even before BIP-352 was officially merged
• BitBox02 became the first hardware wallet with sending support (October 2024), using DLEQ proofs to verify correct output generation
• Sparrow Wallet added sending support in version 2.3.0 (October 2025)
• BlueWallet has development in progress with a typescript library released

Receiving support: More limited, as it requires full scanning infrastructure. Cake Wallet has full implementation. Most wallets are waiting for descriptor and PSBT standards to mature before committing resources.

Infrastructure standards

Two key BIPs have recently been finalized:

BIP-392 (Silent Payment Descriptors): Merged in 2025-2026, defines the sp() descriptor format for output script descriptors. This enables descriptor-based wallets to support Silent Payments without custom code.

BIP-375 (Sending Silent Payments with PSBTs): Merged January 2025, specifies how to send Silent Payments using PSBTv2. This is critical for hardware wallet support, as the output script can’t be computed until all inputs are added.

These standards matter more than most coverage suggests. Without them, every wallet needs custom Silent Payments code. With them, it’s plug-and-play.

The path forward

I think Silent Payments will succeed as a receiving protocol, not a general payment method. The scanning burden is too high for casual users, but for public figures, donation addresses, and merchants running full nodes anyway, it’s perfect.

The light client challenge is the biggest barrier. Current research focuses on tweak data servers (trusted servers provide 33-byte summed public keys per transaction), BIP158 compact block filters, and transaction cut-through to reduce bandwidth.

As descriptor and PSBT support matures, expect more wallets to add sending support. Network effects will follow: the more wallets that can send, the more useful it becomes to publish a Silent Payment address.

Privacy is a toolkit, not a binary

Bitcoin privacy isn’t about finding the “best” technique. It’s about understanding the trade-offs and using the right tool for the job.

CoinJoin breaks transaction graphs at the cost of coordination and on-chain visibility. PayJoin poisons blockchain heuristics during natural payment flows. Silent Payments eliminate address reuse for static receiving addresses.

Each technique has gotten better over the past decade. CoinJoin coordinators are more decentralized. PayJoin is standardized in BIP-78. Silent Payments have moved from research to production with finalized BIPs and growing wallet support.

The tools exist. The infrastructure is maturing. What’s missing is awareness: most Bitcoin users don’t know these techniques exist or when to use them.

That’s changing. Slowly, like a goat picking its way up a rocky slope, but changing nonetheless.

Sources

Sources: BIP-78: A Simple Payjoin Proposal, BIP-352: Silent Payments, BIP-375: Sending Silent Payments with PSBTs, BIP-392: Silent Payment Descriptors, Wasabi Wallet zkSNACKs Coordinator Shutdown Announcement, Samourai Wallet Fork: Ashigaru Announcement, BitBox02 Silent Payments Support Announcement, Bitcoin Optech Newsletter on Silent Payments Light Client Bandwidth, Cake Wallet Early Silent Payments Implementation (Reddit Discussion, May 2024), Sparrow Wallet v2.3.0 Release Notes, BlueWallet Silent Payments Library (GitHub). Data/status as of March 11, 2026.