Chapter 20: Bitcoin Privacy and Monetary Layers

"Bitcoin itself cannot keep a user anonymous; external IP tracking and transaction analysis can reveal identities."

Hal Finney, Bitcoin Forum (2010)^1^

Introduction

Chapter 19 established Bitcoin as sound and resistant money. Those strengths do not make Bitcoin private by default. This chapter turns to Bitcoin's actual privacy model. It begins with the attacks that make privacy necessary, then turns to the primitives and the layers built to defeat them.

The point is neither maximalist evangelism nor dismissal. Bitcoin's base layer exposes real information, and the chain-analysis industry has spent more than a decade building tools to exploit that exposure. Privacy on and around Bitcoin comes from understanding what those tools can see, then applying layered design and disciplined tool choice against them. The chapter proceeds in that order: first the attacks against base-layer privacy, then the script primitives that higher layers depend on, then CoinJoin, PayJoin, and CoinSwap at the base layer, Lightning, Spark, and Ark off-chain, Chaumian ecash with its custodial tradeoff, and finally the client-side validation designs that push privacy further at the cost of maturity.^1^

20.1 How Base-Layer Privacy Fails

A Public Ledger by Design

Bitcoin's blockchain is public. Every transaction ever made is visible to anyone. Amounts, addresses, and timing are all recorded permanently, and the permanence is the point: it is what allows nodes to verify the ledger without trusting any operator. The same property that enables trustless verification also underwrites the privacy attacks that follow. Every heuristic in the chain-analysis toolkit is a way of squeezing information out of data that the protocol publishes by necessity.

The attacks compose. Individually, most are probabilistic; together, they collapse the anonymity set toward a point. Understanding them in roughly the order of severity is also the order of the historical arc: address reuse was the first documented leak, the common-input-ownership heuristic became the industrial workhorse, change detection extended clusters forward in time, timing and network analysis added an IP layer, and KYC linkage anchored the whole graph to real identity.

Address Reuse: The Foundational Leak

An address reused across multiple payments collapses every associated output into a single cluster without any further analysis. All UTXOs held at that address are controlled by the same private key by definition. Every payment into and out of the address is publicly joined on the blockchain forever. Reuse also chains outward: whoever paid the address, whoever the address paid, and every observer of the chain obtains a full ledger of the owner's activity at that location.

Modern hierarchical deterministic wallets, specified in BIP32 in 2012 and extended through BIP44, BIP84, and BIP86, eliminate the most common pathway to reuse by deriving a fresh address from a single seed on every receive and routing change to a separate derivation path. The UX problem the specifications solved was backup durability: pre-hierarchical deterministic wallets kept a finite reserve of pregenerated keys, so an old backup became stale after the wallet exhausted that reserve. Privacy gains followed almost as a side effect.^2^ Reuse persists, however, in categories that sit outside normal wallet flows: donation addresses embedded in forum signatures, GitHub READMEs, and social profiles; mining pools that pay miners to fixed addresses; older exchange deposit addresses; paper wallets and single-address brain wallets; and ransomware payment addresses that attackers deliberately reuse across victims. Each reused address is a cluster anchor that the rest of the chain-analysis toolkit can grow outward from.

The Common-Input-Ownership Heuristic

If a transaction has more than one input, the inputs are presumed to be controlled by the same entity. The reason is cryptographic: spending a UTXO requires a valid signature for its scriptPubKey, so combining multiple inputs in one transaction requires simultaneous access to all the corresponding private keys. Absent deliberate coordination between parties, the only reason to combine inputs is that one wallet holds all of them.

The heuristic appears in the Bitcoin whitepaper's own discussion of privacy and was formalized against the full chain in Meiklejohn et al., A Fistful of Bitcoins, in 2013.^3^ The paper used the common-input-ownership heuristic together with change detection to collapse roughly twelve million addresses into about 3.4 million clusters. It remains the workhorse of the blockchain-analysis industry, applied now at chain scale by every major compliance vendor. The heuristic fails when a transaction's inputs come from different parties, which is the entire design goal of CoinJoin and PayJoin. In practice, however, most transactions are not CoinJoins, most users never use privacy tools, and a single KYC touchpoint anywhere in a cluster's history attaches a real-world label to the whole cluster forever.

Change Detection

A one-input-two-output transaction, which is the ordinary consumer pattern, has one output paying the counterparty and one output returning change to the sender. Identifying which is which lets the analyst extend the sender's cluster forward in time by treating the change output as the seed of the next transaction. Stacked with the common-input-ownership heuristic, correct change detection produces the "peel chain" pattern that drives transitive cluster growth across the chain.^4^

Several heuristics stack to make this work. The strongest is the reused-address heuristic: if one output goes to an address that has been used before and the other goes to a fresh address, the reused one is almost certainly the payment and the fresh one is change, because wallets generate change addresses automatically while payment addresses are defined by the recipient manually. Wallet fingerprinting identifies which output was generated by the same software that built the transaction by matching script type, ordering conventions, and behavioral quirks.

The round-number heuristic notes that humans pay in round amounts, so an output equal to one Bitcoin or to a hundred dollars at the current exchange rate is almost always the payment, and the non-round leftover is change. The unnecessary-input heuristic notes that rational coin selection never includes inputs that are not needed to cover the payment; if one output could have been funded with a strict subset of the actual inputs, that output is change and the other is the payment. Script-type matching observes that wallets usually spend and change in the same script type, so a transaction whose inputs are all P2WPKH and whose outputs are one P2WPKH and one older type marks the P2WPKH output as change. Replace-by-fee behavior marks change too: when a wallet bumps fees on an unconfirmed transaction, it almost always pays the extra fee by reducing the change output amount, so the output whose value shrinks between two mempool versions is change.

No single one of these is decisive. In combination, they identify change correctly often enough to keep the peel chain extending. The analyst needs to be right only most of the time.

Timing and Network Analysis

Chain-level heuristics operate on what the ledger records. Timing and network analysis operate on what happens around the ledger, before and after confirmation.

The most direct network-layer attack runs many Bitcoin full nodes as listening posts on the peer-to-peer network. When a new unconfirmed transaction appears, the listening nodes record which peer sent them the first notification. Under honest broadcast behavior, the first peer to announce a transaction is likely the originating node, which ties the transaction to an IP address. Pre-2015 Bitcoin Core broadcast new transactions to all peers simultaneously, which made this attack close to trivial. Modern Bitcoin Core uses randomized per-peer exponential delays that weaken but do not defeat the attack when the adversary holds many vantage points. The LinkingLion entity, documented by the researcher 0xB10C in 2023, has operated this kind of attack against Bitcoin and Monero from specific autonomous systems since at least 2018, opening short-lived listening connections to reachable nodes with a rotating pool of fake user agents.^5^ Dandelion++, a defense that propagates transactions through a random stem of relays before broadcasting normally, has been deployed in Monero since 2020 but has not been merged into Bitcoin Core.

Timing also leaks within the ledger itself. Two transactions broadcast within milliseconds of each other probably share an originator, diurnal activity patterns leak time zone and therefore geographic region, and sustained automation with low jitter identifies mining-pool payouts, exchange rebalancers, and arbitrage bots. Cross-chain bridge deposits and withdrawals correlate by amount and characteristic delay. Lightning payments leak routing information through HTLC hold times and through probing attacks that learn channel balances by sending deliberately invalid payments. None of these is decisive on its own. In combination with on-chain heuristics, they collapse the anonymity set further.

KYC Anchors and the Analysis Industry

The attacks above produce clusters of addresses. Turning a cluster into a person requires an anchor to a real identity, and the chain-analysis industry has built its business around collecting those anchors. Every major centralized exchange collects know-your-customer information under anti-money-laundering regulations: legal name, address, government ID, sometimes phone and banking details. Deposit and withdrawal addresses tied to KYC'd accounts are labeled inside the exchange's internal systems and shared with compliance vendors through commercial contracts, with governments through subpoenas and mutual legal assistance treaties, and with outside researchers through deposit-address harvesting. One KYC touchpoint anywhere in a cluster's history labels the cluster's real-world owner for good. The FATF Travel Rule, adopted in 2019 and rolled out globally through 2024, requires virtual-asset service providers to share originator and beneficiary information for transfers above certain thresholds, extending the KYC linkage across the industry.^31^

Chainalysis, Elliptic, TRM Labs, Mastercard's CipherTrace, and a long tail of smaller vendors sell the resulting capabilities to banks, exchanges, governments, and law-enforcement agencies.^29^ The tooling ranges from real-time transaction scoring to forensic investigation platforms. The probabilistic nature of the underlying heuristics is often understated in marketing and in court; the Bitcoin Fog prosecution of Roman Sterlingov in 2024 became a flashpoint over whether chain-analysis attribution methodology meets ordinary standards for scientific evidence.^30^ The industry has also opposed Bitcoin privacy upgrades when those upgrades threatened its product. Its incentives are what they appear to be.

Wallet Sync: Where the Wallet Meets the Chain

The attacks above describe what an adversary sees when they read the chain. Before the adversary reads the chain, the user's wallet has to read it first, and every query a wallet makes is a message to some node about which addresses matter to the user. The wallet's sync architecture is the chokepoint where on-chain privacy meets network-layer privacy, and different architectures leak different amounts to whoever the wallet is talking to.

A self-hosted full node is the privacy-maximal architecture. A validating node downloads every block since genesis (~700 GB of storage, ~80–100 GB growth per year, 6–24 hours of initial sync on consumer hardware) and keeps the UTXO set locally. The wallet queries the node over localhost RPC; no remote party learns which addresses the wallet watches, which outputs it holds, or which transactions it is waiting for. The only outbound signal is transaction broadcast, a single message that can be wrapped in Tor. Pruned nodes (reduces storage to ~5–10 GB) preserve full validation while dropping historical blocks from disk, so the privacy properties hold without the full archival footprint. The standard sovereign setup runs Bitcoin Core as a background service with a desktop wallet (Wasabi, Sparrow, or Core's own wallet) talking to it locally; all history sync, fee estimation, and balance queries go through the local node.^6^

Electrum and Electrum-protocol wallets use a different architecture: the client sends address-level queries to an Electrum server which indexes the entire chain by script-hash. The server returns UTXOs and history directly in seconds. The privacy posture is the worst of the practical architectures because every address the wallet watches arrives at the server in a single connection; the server learns the full wallet cluster, balance, history, and IP address at once. The remedy is to run the Electrum server yourself on the same host as your full node. ElectrumX (Python), electrs (Rust), and Fulcrum (C++) are the three standard self-hosted implementations, with electrs shipping as a default component in several sovereign-node distributions. Self-hosted Electrum preserves the fast wallet UX while removing the third-party leak: when the server is the user, no one else sees anything.

BIP 37 bloom filters, introduced by Mike Hearn and Matt Corallo in 2012, were the first light-client protocol on Bitcoin's peer-to-peer network. The design was simple: the wallet constructs a Bloom filter over its addresses, sends it to a serving full node, and receives only the transactions that match. The privacy claim was that the filter's false-positive rate would obscure which addresses the wallet cared about. The privacy claim was false. Gervais, Karame, Gruber, and Capkun showed in 2014 that a serving node observing even one filter could substantially narrow the wallet's address set, and that intersecting filters from the same wallet recovered addresses with near-certainty. Jonas Nick's 2015 measurement against live BitcoinJ deployments confirmed that the effective attack recovered nearly all of a wallet's pubkeys from one observed filter. Bitcoin Core disabled BIP 37 serving by default in release 0.19.0 (November 2019); the protocol was never formally deprecated, but it is no longer served by the majority of the network.

BIP 157/158 compact block filters, specified by Olaoluwa Osuntokun, Alex Akselrod, and Jim Posen in 2017, inverted the direction of the leak. Instead of the wallet sending a filter to the server, the server computes a deterministic Golomb-coded filter (roughly 20–30 KB per block) covering every scriptPubKey in the block, and every wallet downloads the same filter and matches locally. The server never sees what the wallet is watching; the filter is the same for everyone. The residual leaks are network-level (the wallet's IP remains visible) and block-request-timing (on a filter match the wallet downloads the full block, and requesting rare blocks from a single peer reveals which blocks contain transactions of interest). Downloading matched blocks from rotating outbound peers mitigates the second attack; Tor handles the first. Bitcoin Development Kit (BDK) exposes the filter primitives to wallet developers, and the protocol is served by btcd and by Bitcoin Core's compact block filter index.^7^

Wasabi Wallet, launched by zkSNACKs in August 2018, pioneered the use of client-side block filtering in a consumer Bitcoin privacy wallet. Before v2.6.0, Wasabi served custom filters from its own backend because BIP 157/158 was not yet standardized or widely deployed when Wasabi's architecture was built. Those filters used a specific construction including only native SegWit script types, which made them smaller in practice than full BIP 158 block filters covering every scriptPubKey. Wasabi migrated to standard BIP 158 filters in v2.6.0 (May 2025), which also lets users point the wallet directly at their own Bitcoin Core node without any intermediate server.

The resulting tier structure tracks how much the wallet leaks to its serving peers. A full node leaks nothing address-specific. A BIP 157/158 client leaks block-match timing and IP. A self-hosted Electrum server leaks nothing to the outside world while keeping Electrum's UX. A third-party Electrum server leaks the entire wallet cluster. A BIP 37 client, if one still existed in production, leaks nearly as much as third-party Electrum. The order reflects what the wallet's sync channel tells its counterparty about the user, and it is the order in which wallet architectures should be preferred.

Miner-Layer Protocol Changes

Stratum V2, the successor to the mining pool protocol Bitcoin has used since 2012, is primarily a security upgrade to the miner-to-pool channel. The V1 protocol runs cleartext over TCP, which leaks the work stream to any network observer between the miner and the pool and lets an in-path adversary redirect hashrate through hashrate-hijacking attacks that were documented repeatedly across the 2010s. V2 encrypts the entire miner-to-pool connection using the Noise framework with an AEAD cipher, which closes the in-path attack class and the passive-observation leak together. On top of that security base, V2's optional Job Declaration extension lets the miner construct their own block templates; the pool no longer chooses which transactions enter pooled work, so a pool operator who tried to censor specific transactions in pooled hashrate would lose the hashrate to a self-declaring miner.

Braiins Pool, DEMAND Pool, and Public Pool are the production Stratum V2 deployments at the time of writing. OCEAN Pool implements the parallel DATUM protocol, which uses a different mechanism (a transparent payment-settlement record on the pool's own Bitcoin transactions) to achieve the same non-custodial and censorship-resistant properties V2's Job Declaration targets. Adoption of either mechanism is incomplete, and the adoption curve matters for the censorship properties of the chain more than for any single miner's privacy.^8^

Dandelion++, the transaction-propagation defense Monero deployed in 2020, has not been merged into Bitcoin Core because the design introduces denial-of-service vectors at the stem relays that the Bitcoin Core review process has not found acceptable. The practical alternative adopted by privacy-focused Bitcoin wallets is to broadcast each transaction under a fresh Tor identity: the wallet opens a new Tor circuit, connects to a single randomly chosen Bitcoin node it has never connected to before, sends the transaction, and tears down both the connection and the circuit. Wasabi Wallet introduced this pattern and Bitcoin Core now supports it through its -onlynet=onion and per-connection circuit isolation options. The remaining attack surface is timing correlation between the wallet's Tor circuit and the first peer's gossip to the rest of the network, which weaker adversaries cannot exploit but a global passive observer still can. The structural point across these protocols is that network-layer privacy on Bitcoin is an engineering program that has produced partial gains the wallet's operator must opt into.

What the Base Layer Therefore Does Not Provide

Taken together, the attacks explain why the base layer does not provide transaction confidentiality (amounts are visible), sender-receiver unlinkability (addresses are visible and clusterable), denial that a transaction occurred (every transaction is public), or protection from chain analysis (the patterns are analyzable by anyone with the resources). The layers built on top of the base layer exist to defeat specific combinations of these attacks, and each layer does so at a specific cost. The rest of the chapter examines what each one accomplishes and what it leaves unchanged.

20.2 Programmable Money: Script Primitives

Bitcoin Script

Each transaction output contains a script specifying the conditions that must be satisfied to spend it. Bitcoin Script is deliberately non-Turing-complete and cannot loop or access external state, which makes scripts predictable and auditable and limits programmability to financial primitives.

Multisignature

Multisignature (multisig) scripts require multiple keys to authorize spending. A 2-of-3 multisig requires any two of three designated keys, enabling shared control without trusting any single party. Legacy multisig pays for that control with on-chain disclosure: the script reveals every participant public key, and the spend reveals which keys signed. Schnorr signatures make the cleaner version practical. MuSig2 and FROST move the threshold logic into an aggregate signing protocol, so the chain sees one public key and one signature while the participant set and threshold remain off-chain.^33^ Threshold ECDSA exists too, but the protocols are more complex and lack the same clean security proof. Corporate treasuries, inheritance schemes, exchange hot wallets, and escrow arrangements all use the primitive to replace a trusted custodian with programmable shared custody.

Timelocks

Timelocks prevent spending until specified conditions are met. Two types exist:

Absolute timelocks (CLTV, CheckLockTimeVerify) prevent spending until a specific block height or timestamp. A transaction locked until block 900,000 cannot be spent before that block, regardless of who holds the keys.

Relative timelocks (CSV, CheckSequenceVerify) prevent spending until a specified time has elapsed since the output was created. An output locked for 144 blocks cannot be spent until 144 blocks (approximately one day) after its creation.

Timelocks enable time-delayed transactions, vesting schedules, and, critically, the revocation mechanisms that make payment channels secure.

Hash Locks

Hash locks require revealing a secret value (preimage) whose hash matches a specified hash. The script contains a hash; spending requires providing the preimage.

This seems simple but enables powerful constructions. If Alice wants to pay Carol but has no direct channel, she can route through Bob using hash locks: Alice pays Bob conditional on Bob revealing a secret that only Carol knows. Bob pays Carol the same way. When Carol reveals the secret to claim her payment from Bob, Bob learns the secret and can claim his payment from Alice. The payment atomically succeeds or fails across the entire path.

Hash Time-Locked Contracts (HTLCs)

Combining hash locks with timelocks creates Hash Time-Locked Contracts (HTLCs). An HTLC can be spent in two ways: by revealing the hash preimage (success path), or after a timeout expires (refund path).

HTLCs are the foundation of the Lightning Network. They enable trustless multi-hop payments: either the payment completes across all hops when the final recipient reveals the preimage, or all participants recover their funds after timeout. No intermediate routing node can steal funds or block payments indefinitely.

What These Primitives Do

Together these primitives transform Bitcoin from simple digital gold into programmable money. Multisig replaces trusted custodians with shared-key control; timelocks replace trusted schedulers with block-height enforcement. Hash locks and HTLCs go further: they enable conditional, multi-hop payments that no escrow agent needs to mediate.

Taproot (BIP 341, activated November 2021) adds a privacy benefit to the script-primitive stack that older output types could not offer.^32^ Every Taproot output commits to a Merkle tree of alternative spending scripts, and a spender who uses any one leaf reveals only that leaf. The other branches of the tree remain unpublished and indistinguishable from bytes that were never written. A 2-of-3 multisig with a 1-of-1 cooperative path and a timelocked recovery path spends on-chain as a single Schnorr signature when the cooperative path is taken, with the other branches never appearing. Chain analysis cannot tell from the spending transaction whether the output was a simple single-sig, a complex multi-party script, or anything in between. The script-path visibility rule turns the expressive power of Bitcoin script from a privacy cost into a privacy asset: complexity that exists only to be used occasionally is hidden by default, and only the path exercised is disclosed.

Each primitive removes a category of trusted intermediary. Together they enable Layer 2 systems like Lightning that inherit Bitcoin's settlement security while gaining speed and stronger privacy.

20.3 Privacy Solutions: Collaborative Transactions and Swaps

CoinJoin: Collaborative Transactions

CoinJoin combines inputs from multiple users into a single transaction with multiple outputs.^9^ Participants are not paying each other; each person sends funds to themselves. The privacy gain comes from breaking the link between inputs and outputs: if Alice, Bob, and Carol each contribute one input and each receive one output of equal value, an observer cannot determine which output belongs to which input.

CoinJoin requires coordination between participants. Two main approaches have emerged.

JoinMarket, the earlier implementation, uses market-based coordination: "takers" initiate CoinJoin rounds and pay "makers" for liquidity.^34^ Each taker coordinates its own transaction, distributing coordination across many participants instead of centralizing it in a single service. The transaction has one equal-denomination output for each participant, which is the output set that receives the anonymity. A taker can also make a payment inside the CoinJoin by adding a separate payment output while preserving the equal-denomination mix output; makers provide liquidity and earn fees, but they cannot direct a payment output because they do not control the transaction template. Takers must run more complex software and pay for participation, but no external coordinator can be shut down.

Wasabi 1.0 used a similar equal-denomination model with a central coordinator and Chaumian blind signatures to enable anonymous registration of the equal amount output. Wasabi 2.0 changed the construction with WabiSabi, which uses keyed-verification anonymous credentials (KVACs) to issue blind signatures over arbitrary amounts. Participants can register arbitrary-value inputs and choose output values that fit their wallets instead of forcing every private output into one denomination. By avoiding repetitive equal chunks, WabiSabi spends less block space and improves both wallet efficiency and privacy.

It also generalizes CoinJoin payments: any participant can register payment outputs during a round, and the coordinator cannot distinguish a payment output from a self-transfer output. This aggregation produces much larger transactions with higher anonymity sets than JoinMarket's distributed model typically achieves. The tradeoff is that static coordinators present censorship challenges: a coordinator can be taken offline through legal pressure or technical attack. The WabiSabi protocol is open; anyone can run a coordinator, and multiple coordinators can operate simultaneously. When Wasabi's original coordinator ceased operation due to regulatory pressure, alternative coordinators showed that the protocol itself was not tied to one operator, even if liquidity and usability still depended on implementation details.^39^

PayJoin: Payment-Integrated Coinjoining

PayJoin is designed explicitly for payment transactions. Instead of Alice sending Bob a payment in a simple transaction, both Alice and Bob contribute inputs. The result looks like an ordinary payment, not a CoinJoin.

PayJoin operates on a different privacy model than CoinJoin. Instead of creating anonymity through mixing with other users, PayJoin is steganographic: it makes privacy-enhancing transactions indistinguishable from ordinary transactions. CoinJoin's equal-amount outputs create an obvious fingerprint on the blockchain; PayJoin transactions look like any normal payment.

The privacy benefit is structural. PayJoin breaks the common input ownership heuristic, the assumption that all inputs in a transaction belong to a single entity. Chain analysis depends heavily on this heuristic. When PayJoin transactions are indistinguishable from regular transactions, analysts cannot know which transactions violate the heuristic, degrading the reliability of clustering analysis across all transactions, not just PayJoin ones. Wider PayJoin adoption thus improves privacy for the entire network by introducing uncertainty into chain analysis assumptions.

PayJoin also hides the payment amount from the chain's plain arithmetic. In a normal payment, the recipient output is the payment amount. In a PayJoin, the receiver adds their own input value on top, so the output they receive is no longer equal to the sender's payment. The protection is conditional: if an adversary later separates sender-owned inputs from receiver-owned inputs, the actual payment amount can be reconstructed. The same construction can improve block-space efficiency. A receiver can add unrelated payments to other people into the same transaction, or coordinate additional participants' inputs and outputs, turning the receiver into the coordinator of a multiperson CoinJoin around the payment. That saves block space by combining several economic transfers into one transaction, but it does not have the coordinator privacy like WabiSabi; the receiver coordinating the transaction can see the participant roles they arrange.

Limitations

CoinJoin and PayJoin improve privacy but have distinct limitations. CoinJoin requires other participants, and the effective anonymity depends on the liquidity available in the round. WabiSabi removes the fixed-denomination constraint that made older coordinator designs produce obvious change, so unequal amounts are not the core limitation. The remaining constraints are operational: a coordinator can deny service, set admission policy, choose round parameters, or disappear under legal pressure; one coordinator tends to attract most liquidity, making that coordinator the practical meeting point even when the protocol permits many coordinators. Rounds also depend on participant liveness. A participant who fails to sign can force a blame round, and Sybil liquidity can reduce effective anonymity if an adversary pays the fees to join with many coins. After the CoinJoin, careless spending can still undo the privacy by merging histories that the round separated.

PayJoin's limitations are different in kind. The steganographic claim that PayJoins look like ordinary payments is conditional. The unnecessary-input heuristic, analyzed against PayJoin by Adam Gibson and LaurentMT in 2018 and formalized by Ghesmati, Fdhila, and Weippl in 2022, flags transactions whose inputs exceed what rational coin selection would have produced; LaurentMT's measurement found roughly a third of two-output transactions violating one of the variants, so PayJoins that fall into that third are statistically detectable.^10^ Wallet fingerprints break the claim along separate axes: mixed input script types in particular announce multi-party origin so reliably that BIP 78 disallowed them entirely until September 2024, and sequence values, nLockTime, BIP 69 input ordering, and signature R-value patterns survive the join with their original fingerprints intact.

The construction also exposes one of the receiver's UTXOs to the sender by design, which a malicious sender can exploit as a deanonymization channel against the receiver they are paying; the probing variant against a public merchant endpoint is bounded by the fact that the sender's first message in BIP 78 is a fully signed and broadcastable original transaction, so a sender that aborts to probe risks the receiver broadcasting that fallback and pocketing the payment. Operationally, the receiver pays the fee for the input they contribute, replace-by-fee bumping requires both parties to coordinate again because both signed the transaction, and BIP 78's default output-substitution setting lets a compromised PayJoin server redirect payment unless the sender opts out.

Infrastructure cost has been the binding constraint on adoption: BIP 78 required the receiver to host a TLS-protected HTTP endpoint reachable at payment time, and BIP 77's async successor (merged in May 2025) lifts that requirement only by routing traffic through an OHTTP directory whose sole production deployment, payjo.in, becomes a new trust principal.^11^ Six years after BIP 78, production sender-and-receiver implementations number in the single digits, Bitcoin Core has no native integration, and the chain-analysis-uncertainty benefit the steganographic argument relies on is therefore real but small.

Both tools also require users to understand and correctly apply them, adding implementation complexity on top of the protocol-level limitations on each side.

CoinSwap: Cross-Transaction Unlinkability

CoinSwap is the other on-chain approach to severing the transaction graph. Where CoinJoin combines multiple users' inputs and outputs into a single transaction, a CoinSwap has two parties exchange outputs across separate transactions: Alice's coin goes to Bob's address in one transaction, and Bob's coin goes to Alice's address in another. An outside observer sees two ordinary-looking sends. No transaction fingerprint distinguishes a CoinSwap from a pair of unrelated payments, because each transaction has one input and two outputs and carries no on-chain coordination signal. The link between the coin that was spent and the coin that was received disappears across multiple hops: chain analysis can follow a coin forward to a swap counterparty's address but cannot determine whether the value continued in that direction or whether the counterparty's subsequent spend represents the swapped coin or an unrelated one.

The privacy property is plausible deniability at scale. With CoinJoin, chain-analysis tools can identify the transaction as a mixing event, even if they cannot determine which output belongs to which participant. With CoinSwap, they face a more difficult problem: there is no mixing event to identify. The swap looks like any other spend, and a chain of swaps through multiple counterparties produces a transaction graph where the economic flow is undetectable, not ambiguous in the way a CoinJoin is ambiguous.

The construction is mainly theoretical on Bitcoin at present. The atomic swap protocol, in which a hash-timelock contract enforces that both legs of the exchange either complete or both revert, dates to Tier Nolan's 2013 proposal on the Bitcoin Talk forum.^35^ Same-chain CoinSwaps for on-chain privacy have been explored in research and in early prototype tooling, but no widely deployed implementation exists with meaningful usage. The demand-side coordination problem is the binding constraint: finding a willing counterparty with the right output size at the right time requires either a public market (which leaks information about intent) or a trusted meeting point (which reintroduces a coordination server).

Lightning is the off-chain instantiation of the same primitive. Each Lightning payment hop is an atomic CoinSwap between adjacent channel partners, enforced by Hash Time Locked Contracts on the same elliptic-curve assumptions Bitcoin uses for spending. For an Alice-to-Carol payment through Bob, Alice and Bob execute one swap while Bob and Carol execute another; neither Bob nor Carol can link Alice's incoming HTLC to Carol's outgoing payment without additional information. The construction pushes CoinSwap coordination off the base layer entirely, where it executes at millisecond latency with no on-chain footprint per payment. Lightning is, in this sense, the production deployment of the CoinSwap model, shifted into the channel-graph layer.

20.4 Non-Custodial Off-Chain Payments

Lightning, Ark, and Spark are the three off-chain constructions examined here that move Bitcoin payments off-chain while preserving each user's ability to unilaterally return to the base layer without counterparty cooperation. They differ in how liquidity is managed, what the operator sees, and what scripting capability the construction exposes, but all three leave custody with the user. Custodial constructions are the subject of the next section.

Lightning Network: Payment Channels

The Lightning Network enables off-chain transactions through payment channels.^12^ Two parties lock bitcoin in a multisignature address, then exchange signed transactions updating the balance between them without broadcasting each update to the blockchain. As long as the two parties continue to cooperate, the channel can handle arbitrarily many payments; only the eventual close settles back to the base layer. Channels can also be linked, so that Alice pays Carol through Bob whenever channels exist between Alice-Bob and Bob-Carol, and this routing extends the payment graph far beyond the set of direct channel partners. A small number of well-connected nodes can therefore support a large number of payments among parties that never open channels directly with each other.

Instant Finality

Base-layer confirmation is probabilistic and slow: blocks arrive on average every ten minutes, intervals vary widely, and prudent recipients wait for additional confirmations against reorg. Lightning replaces that wait with an immediately enforceable claim inside the channel structure, a signed commitment transaction the recipient can broadcast if needed. Settlement is cryptographic within the channel instead of probabilistic on the chain: either the recipient reveals the preimage and the payment succeeds across all hops atomically, or timeouts expire and funds return to senders. Point-of-sale, micropayments, and machine-to-machine flows become practical once payment overhead collapses to milliseconds.

Privacy Properties and the Channel-Graph Model

Lightning offers privacy properties the base layer lacks. Payments within channels are invisible on the blockchain; only channel opening and closing appear on-chain. Onion routing means each intermediate node learns only its predecessor and successor, not the full path. Announced channel capacities are visible, but the balance between the two channel parties is private.

The privacy model differs from base-layer Bitcoin instead of improving on it in a single direction. The public channel graph reveals network structure while payment paths through it remain private. Routing nodes see the amount passing through them, but payments can be split across multiple paths so no single routing node necessarily sees the full amount. Topology stays public while actual usage stays hidden.

Privacy Limitations

Lightning's privacy properties are weaker than they might appear.^13^

Balance discovery through probing is a serious vulnerability. An adversary can send probe payments through target channels, observing which amounts succeed and fail. Research has shown efficient balance estimation under specific network conditions, often at low cost to the attacker because probes are designed to fail. Through systematic probing, adversaries can infer the balance distribution in channels they can route through.

Routing nodes observe payment amounts passing through them. While onion routing hides the payment's origin and destination, intermediate nodes see values. A routing node that appears in many paths gains statistical information about network payment flows.

Lightning Service Providers (LSPs) present particular privacy concerns. Many mobile wallets connect to a single LSP for channel management and routing. The LSP learns the user's node identity and network address, along with much of the payment activity if payments route through the LSP's node. This reintroduces the trusted third party that Bitcoin was designed to eliminate.

On-chain channel opening and closing transactions link Lightning activity to base layer transactions. Clustering analysis can connect these to other user transactions. Force-close transactions can also reveal channel states at closure time.

One 2021 cross-layer deanonymization study found that combining on-chain and Lightning data could link 43.7% of Lightning nodes in its dataset to associated Bitcoin addresses.^14^ The interaction between layers creates information leakage that neither layer alone would reveal.

Lightning Limitations and Current State

Lightning has operational limitations beyond privacy. Channels require locked capital, receiving capacity requires counterparties to lock funds, payments require online presence or watchtower services, and optimal operation requires liquidity management across channels. Large payments may fail to find paths with sufficient liquidity.

Privacy improvements are actively being developed and deployed. Route blinding, especially in newer BOLT 12-style flows, can improve receiver privacy by hiding node identity and parts of the path from counterparties, though support remains implementation-dependent. Payment splitting across paths reduces information available to any single routing node. Trampoline routing can further reduce how much topology some senders or routing intermediaries learn, but its privacy effects depend on how it is implemented. The Lightning protocol undergoes continuous development with regular specification updates; many privacy concerns identified by researchers are being addressed through protocol improvements, though some, such as balance probing, remain structural challenges inherent to the routing discovery process. Lightning remains developing technology whose privacy properties shift with implementation choices and network conditions alike.

Ark: Shared-UTXO Payment Rounds

Ark, specified by Burak Keçeli starting in 2023, is an off-chain construction that removes Lightning's liquidity-management burden at the cost of a different trust model.^15^ Instead of opening a channel with a specific counterparty and managing inbound and outbound capacity, a user joins an Ark round by handing bitcoin to a shared UTXO that the Ark server controls, receives virtual UTXOs inside that shared UTXO whose value is immediately spendable within the Ark protocol, and settles to a new shared UTXO at the end of each round. Users can receive payments without opening channels in advance, which is the usability gap Lightning has not closed for mobile wallets whose receiving capacity is priced and provisioned through Lightning Service Providers.

The trust model is different from Lightning's. A misbehaving Lightning counterparty cannot steal the channel's funds because the revocation-key construction lets the honest side unilaterally close on any stale channel state they publish. An Ark server likewise cannot steal user funds, because every vTXO carries a unilateral-exit transaction path its owner can broadcast directly to the base layer. The attack the Ark server can mount is griefing: by refusing to continue rounds, the server forces users into on-chain exits that are expensive in fees during congested periods.

The construction also reveals more information to the server than Lightning reveals to any single channel partner, because the server participates in every user's settlement instead of only a subset. Arkade, the primary production implementation, mitigates part of this exposure by running its signing key inside a Trusted Execution Environment and routing user-to-signer communication through end-to-end encryption, so the operator's infrastructure cannot read individual transaction content even though it coordinates batch settlement.

Arkade's programmable execution environment also supports spending conditions that go beyond what on-chain Bitcoin Script can express, because the off-chain vTXO layer is not constrained by base-layer script limits. In principle this includes zero-knowledge payment schemes where proofs over VTXO outputs replace plaintext amounts and counterparty identities, collapsing operator visibility toward what Chaumian ecash achieves while preserving unilateral exit. That capability remains theoretical at the time of writing, with no deployed ZK scheme running over Ark in production. Second is the other production-scale implementation at the time of writing; the construction is new enough that its empirical behavior under adversarial operator conditions has not been tested at Lightning's scale.

Spark: Statechain Transfers

Spark is an off-chain Bitcoin protocol built on statechains, extended with FROST threshold signing across multiple Signing Operators (SOs).^36^ In the base statechain model, a bitcoin UTXO is controlled by a key split between the current owner and a signing service; transferring the coin off-chain means the current owner and the service jointly reassign the key to the recipient, with the service deleting its prior key share so the previous owner cannot spend. Spark extends this to a distributed set of SOs using FROST and introduces a leaf architecture that allows UTXO values to be split and merged off-chain, removing the whole-coin denomination constraint of earlier statechain designs. The chain records nothing until a leaf exits; on-chain, Spark state appears as a chain of singlesig outputs.

The trust model is 1-of-n at the operator level: as long as one SO honestly deletes its prior key share after a transfer, the previous owner's ability to spend is revoked and the new owner's claim is secure. Even if all SOs later collude or are compelled, they cannot move funds without the current owner's signature, since the user is a required co-signer on every transaction. The attack surface the SOs retain is liveness: a coordinated refusal to co-sign forces the user into a unilateral on-chain exit via a timelocked backup transaction, similar in character to the griefing risk an Ark operator holds.

The privacy ceiling is set by what the SOs see during signing. Every transfer passes through the SO set, which observes the amounts, the sender, and the recipient for each leaf. An outside observer watching the chain sees only funding transactions and exits; the SOs see the full transfer graph between those events. Splitting the operator role across multiple SOs reduces the single-point-of-compulsion risk (a subpoena or breach must reach a threshold of operators to reconstruct the full history) but no individual SO is blind to the transactions it co-signs. Spark's operator visibility is therefore higher than Lightning's, where each node sees only its adjacent hops, and higher than Ark's batch model, where the operator sees output amounts at settlement but not the internal transfer graph between rounds.

Comparing Lightning, Ark, and Spark

Lightning, Ark, and Spark make different choices along the same trust-and-privacy spectrum. Lightning distributes trust across the channel graph so that each user trusts only their counterparties and can exit unilaterally against any of them; it pays for that distribution in liquidity-management complexity, inbound capacity constraints, and the balance-probing surface described above. Ark concentrates the coordination role in a single server that cannot steal funds but can grief by refusing rounds and sees more of each user's payment flow than any Lightning counterparty sees; it pays for that concentration by eliminating the inbound-liquidity problem that Lightning has not solved for mobile receivers. Spark, anchored to the statechain model, distributes the signing role across a threshold operator set that collectively sees the full transfer graph, in exchange for instant off-chain transfers without locked liquidity or round participation.

The architectural difference between Ark and Spark that carries the most weight for privacy is scriptability. Ark's vTXO layer runs an off-chain execution environment whose spending conditions extend beyond what base-layer Bitcoin Script can express on-chain. Timelocks, hash locks, threshold signatures, and covenant constructs all apply inside an Ark round, but the off-chain context also admits ZK proof systems that have no direct on-chain equivalent: a ZK payment scheme layered over Ark's vTXO model could blind amounts or sender-receiver relationships from the operator entirely, collapsing operator visibility toward what Chaumian ecash achieves while preserving unilateral exit. Statechain transfers carry no equivalent surface. Each SO must co-sign every state transition, and the signing protocol requires each SO to observe the transaction; there is no script path by which a ZK proof could substitute for the SOs' key contributions. Ark's privacy ceiling is therefore open to future protocol work; Spark's is structurally lower by design.

20.5 Custodial Privacy Layers

Lightning, Ark, and Spark preserve unilateral exit, which is to say each user can reclaim base-layer funds without counterparty cooperation. A second family of privacy layers surrenders that property in exchange for stronger privacy against outside observers, or for confidential amounts, or for receive-offline convenience. The trust model varies across the family, from a single operator to a federation of guardians, and the privacy model varies with it. This section examines the three constructions in order of increasing trust distribution: single-operator mixers, Chaumian mints (single and federated), and the Liquid federated sidechain.

Custodial Mixers as a Privacy Baseline

The crudest route to transaction privacy is to pool funds in a custodian. A centralized Bitcoin mixer accepts deposits from many users, commingles the coins, and returns equivalent amounts from the pool to whichever withdrawal addresses each user specifies. To an outside observer watching the blockchain, the deposits and withdrawals are decorrelated: chain analysis sees that funds entered the operator's cluster and that other funds left it, but not who received what. Against chain-analysis firms and ordinary outside adversaries, the custodian provides real privacy, and this is what Bitcoin mixers have done for more than a decade.

What the custodian does not blind is itself. The mixer operator holds the mapping between deposits and withdrawals by construction, because the operator is the entity moving the coins. When the operator is cooperative, the user's privacy holds against everyone else. When the operator is hostile, subpoenaed, or breached, the user has no privacy at all, and the operator's internal ledger becomes a surveillance dossier of everyone who ever used the service. The prosecution of Roman Sterlingov for allegedly operating Bitcoin Fog turned on exactly this: the operator saw everything, and the investigation was about reconstructing what the operator had seen. A custodial privacy layer that depends on operator honesty has moved the trust problem, not solved it. Ordinary custodial wallets and exchanges share this structure. Holding bitcoin at a custodian pools on-chain activity behind the custodian's addresses, which provides real privacy against outside chain-analysis observers. What varies is the custodian's own practices: an exchange that requires KYC, logs withdrawals by identity, or sweeps funds through poorly-labeled hot wallets hands that information to any adversary who can compel or breach it. The privacy benefit of custody is real but entirely dependent on the operator's data handling, legal exposure, and on-chain hygiene.

Chaumian Ecash: Blinding the Operator

David Chaum's blind-signature scheme, introduced in 1982, solves the operator problem in exactly the place the custodial mixer cannot.^16^ A user prepares a token with a serial number, then blinds the serial number before presenting it to the mint for signature. The mint signs the blinded form without ever seeing the underlying serial. The user unblinds the signed token afterward and holds a valid signature on a serial the mint has no record of. When the user later redeems the token, the mint verifies its own signature on the newly revealed serial but cannot tie the redemption to the specific issuance event.

Applied to Bitcoin, the construction becomes a deposit-and-withdrawal protocol in which the operator genuinely does not know who received which coins. Users deposit bitcoin with a mint and receive blind-signed tokens that function as bearer money warehouse receipts. They transact peer-to-peer in those tokens, or redeem them to bitcoin when they wish to exit. The mint records who deposited and who redeemed but cannot link the two sides of the ledger together. The operator no longer has the information to betray a user even if compelled.

Cashu and Fedimint: Two Deployments, Same Blinding

Two contemporary projects implement this construction on Bitcoin. Cashu operates as a set of independent single-operator mints speaking a common protocol.^17^^37^ Each mint directly runs a Lightning node, so Lightning is the primary payment rail: users deposit and withdraw via Lightning invoices. The privacy properties follow directly from the Chaumian construction: the operator sees amounts and timings but not the user-to-user flow of tokens, and outside observers of the blockchain see only Lightning channels of the operator. The operational simplicity is also the risk: a single operator can fail, be compromised, disappear, or refuse redemptions, and users of that mint bear the full exposure. Mints are cheap to run, so the practical mitigation is that users hold small balances on any one mint and choose operators whose reputations they can evaluate. Due to the privacy of blind signatures, the mint cannot selectively censor one particular user, only inflate the amount of tokens in circulation, or deny redemption globally and steal all users' funds.

Fedimint implements the same blinding with federated custody.^18^^38^ Multiple guardians jointly control the mint's bitcoin reserves using on-chain threshold multisig, so no single guardian can unilaterally steal funds, halt redemptions, or coerce the user. A threshold of guardians must cooperate for any action on the underlying bitcoin. Lightning connectivity comes through independent Lightning Gateways: separate nodes that bridge the federation to the Lightning network and operate outside the federation's trust boundary, so Lightning access does not depend on the federation itself holding channel liquidity. The ecash issuance itself uses a threshold blind signature scheme (TBS) in which each guardian holds only a key share; issuing a blind-signed token requires a threshold of guardians to contribute partial signatures, which means no sub-threshold subset can unilaterally issue or censor tokens. The privacy properties against outside observers are the same as Cashu's, and the blinding of the operator is the same intuition, but the operator now consists of a federation whose members watch each other. The tradeoff is operational: federations must be set up, coordinated, and maintained, which is more demanding than running a single mint and more demanding than using one.

Liquid: Federated Confidential Transactions

Liquid is a federated Bitcoin sidechain operated by a consortium of exchanges and trading firms under Blockstream's coordination.^19^ Its monetary unit is Liquid Bitcoin (L-BTC), a two-way peg to base-layer Bitcoin administered by the federation. Liquid's relevance to this chapter is its Confidential Transactions type, which uses Pedersen commitments and range proofs to hide amounts and asset types on-chain while preserving the federation's ability to audit supply. What Confidential Transactions do not hide is the transaction graph: senders and receivers are visible to any outside observer, and the full payment topology remains public. The privacy gain over base-layer Bitcoin is amount and asset blinding only. Liquid also supports issued assets (tokenized stablecoins and securities tokens) whose amounts ride the same confidentiality machinery.

The trust model is similar to Fedimint's: a federation of known entities jointly controls the peg, any member can observe the transaction graph, and a threshold must cooperate for peg-in or peg-out operations. Privacy against outside observers is weaker than Fedimint's, since the transaction graph is public where Fedimint's ecash flow is not. The federation can, in principle, collude to halt the network or reverse transactions, and the peg depends on the federation honoring redemption. For use cases where amount confidentiality and faster settlement are worth the federation trust (stablecoin issuance, confidential OTC settlement), Liquid has operated continuously since 2018 without incident. For use cases where full transaction-graph privacy or trust-minimization is the requirement, the constructions examined elsewhere in this chapter are the better answer.

Trust Tradeoffs Across the Custodial Spectrum

The custodial layer runs a spectrum along two axes that do not move in lockstep: trust distribution and transaction-graph privacy. Trust distribution increases from single-operator mixers through Cashu's single-operator mints to Liquid's multi-member consortium to Fedimint's threshold-guardian federations. Transaction-graph privacy does not follow the same ordering. Mixers, Cashu, and Fedimint all hide the payment flow from outside observers: chain analysis sees deposits and withdrawals into the operator's cluster but not who paid whom inside it. Liquid hides amounts but leaves the full transaction graph visible on-chain, which means it provides weaker privacy than Cashu or Fedimint against a chain-analysis adversary despite distributing custody across a larger federation.

What is uniform across the spectrum is the absence of unilateral exit. Unlike Lightning, Ark, and Spark, none of these constructions lets a user reclaim base-layer funds without operator cooperation. If the mint or federation goes offline and reserves are lost or seized, the tokens in circulation are unredeemable. They are money substitutes in Mises' sense. Federated models reduce the probability of unilateral operator failure, but the custody risk is present throughout. Sensible practice depends on what amounts, time horizons, and adversary models the user needs to protect against: a user whose primary concern is chain-analysis surveillance benefits most from Cashu or Fedimint; Liquid's transaction-graph visibility and larger, more censorable consortium make it the weakest option on both axes despite its confidential amounts.

20.6 Shielded Client-Side Validation

Moving Validation Off the Chain

All the layers examined so far share a common property: every participant who sees a transaction learns something from it. Base-layer Bitcoin publishes the entire transaction to every full node. CoinJoin and PayJoin publish a transaction whose inputs and outputs are all visible, with privacy coming only from the ambiguity of the join. Lightning hides payment-level activity but publishes the opening and closing of channels, and its routing graph is public by design. Ecash hides the payment graph from outside observers, and the Chaumian construction blinds the mint to which token was issued to whom. What it cannot remove is the mint itself: every ecash token's validity ultimately rests on the mint's blind signature, so the mint is a required counterparty for every issuance and redemption. A user cannot verify coin validity independently; the mint's continued cooperation and solvency are load-bearing assumptions throughout.

Client-side validation inverts this. Instead of every node validating every transaction, the recipient validates the transactions that move coins to them, and the chain is used only for ordering and to prevent double-spending.^20^ The idea originates with Peter Todd's 2013 work on proof-of-publication consensus and was developed most fully in his 2016 paper on state-machine consensus primitives, which introduced the concepts of single-use seals, deterministic transaction expressions, and proof-of-publication as building blocks. A Bitcoin UTXO is already a single-use seal: the outpoint identifies the seal, the script authorizes its closure, and the spending transaction is the proof that it has been closed. Protocols built on top of this observation, most prominently RGB and Taproot Assets, have used Bitcoin as a commitment and ordering substrate for off-chain contract state.

Existing client-side-validation protocols improve privacy over native base-layer transactions, but they do not eliminate the leak. In RGB and similar designs, when a coin is transferred, both the sender and receiver see the full history of the coin, because the proof that validates the current state is the chain of prior state transitions. Coin proofs grow with the length of the transaction history. The on-chain footprint depends on how the commitment is anchored. RGB's recommended method, Tapret, embeds the commitment as a taproot key tweak: the resulting output is indistinguishable from an ordinary taproot spend, so chain analysis cannot identify or cluster RGB transactions from the chain alone. The alternative, Opret, publishes the commitment in an OP_RETURN output, which is visible and clusterable. For Tapret users the binding privacy constraint is not on-chain visibility but counterparty disclosure: the receiver must see the full prior chain of state transitions to verify the coin, so every transfer leaks history to the immediate recipient.

Shielded CSV: Zero-Knowledge Client-Side Validation

Shielded Client-Side Validation, proposed by Jonas Nick, Liam Eagen, and Robin Linus in a 2025 paper, closes both of those gaps by applying zero-knowledge proofs to client-side validation.^21^ The construction uses Proof-Carrying Data, a recursive form of zero-knowledge proof, so that a coin's current holder does not need to see the coin's full history to verify its validity. The sender hands the receiver a succinct proof that the coin in question was produced by a valid chain of Shielded CSV transactions terminating in a legitimate issuance, and the proof's size and verification time are independent of how long that chain is.

What appears on the Bitcoin chain per transaction is 64 bytes of opaque data the paper calls a nullifier, pseudorandom-looking to anyone who does not hold the corresponding receipt. The nullifiers are published as application-layer payload inside ordinary Bitcoin transactions. A Bitcoin full node that is not a Shielded CSV participant treats this payload as raw bytes: it validates the carrier transaction under normal rules, performs no verification on the nullifier itself, and leaves the UTXO set unchanged. Only Shielded CSV participants parse the data, and for them the cost of verifying an entire batch of nullifiers collapses to a single Schnorr verification through the paper's NISSHAC half-aggregation construction. The base chain's role reduces to ordering and proof-of-publication; double-spend prevention is enforced client-side, by Shielded CSV nodes maintaining a key-value store of seen nullifier public keys and rejecting any repeat.

The privacy properties follow from the construction. An outside observer watching the Bitcoin chain sees a stream of 64-byte blobs: amounts, senders, receivers, linkage between transactions, and any off-chain history are all opaque by construction. A receiver validates what they need to accept the coin, and learns nothing about what the sender did with coins they did not transfer. The history that is visible to counterparties in RGB becomes invisible under Shielded CSV, and the commitment graph that chain-analysis could cluster in RGB collapses to a set of nullifiers that resist clustering by construction.

Maturity and Place in the Layer Stack

Shielded CSV is a research proposal with a prototype implementation, not a deployed system. The paper is recent, the construction depends on recursive proof systems such as folding schemes or recursive STARKs, and the efficiency claims the paper makes rest on a deployment path that does not yet exist.

Its place in the layer stack is nevertheless clear. Lightning remains the right answer for low-latency interactive payments at the base of the stack, and ecash provides instant bearer-style privacy today at the cost of custody. Shielded CSV represents the direction the non-custodial privacy frontier is moving: toward designs where the chain carries commitments it cannot read, the receiver validates proofs whose size does not depend on history, and the information leaked to outside observers collapses to what Bitcoin absolutely requires for consensus. Whether Shielded CSV specifically becomes the deployed standard or another zero-knowledge client-side-validation design takes its place, the architectural shift is the point.

20.7 Privacy Coin Comparators

The privacy layers in this chapter all share a design premise: Bitcoin's base-layer ledger is given, and privacy is bolted on. Two families of alternative cryptocurrency reject that premise and build privacy into the base layer itself. Monero and Zcash are the main comparators. Both have operated continuously for roughly a decade. Neither replaces the Bitcoin analysis in Chapter 18, and neither changes the monetary case for Bitcoin made in Chapter 19. Both earn examination here because they illustrate what privacy-at-the-base-layer buys and what it costs. A third comparator, Ethereum, takes neither the base-layer-privacy route nor the Bitcoin layered route: its base layer is fully transparent, but its programmable contract environment has produced a set of application-layer privacy overlays whose architectural position clarifies what the layered model requires and where it runs into enforcement limits.

Monero's Construction

Monero encodes three privacy properties directly into the transaction format. Ring signatures hide which input a transaction is spending. Stealth addresses hide which output a recipient controls. Ring Confidential Transactions hide the amount. Each property is a cryptographic primitive with a body of peer-reviewed theory behind it, and the combination produces a ledger on which a casual observer cannot tell who paid whom how much.

A ring signature, originally proposed by Rivest, Shamir, and Tauman in 2001, is a signature scheme in which the signer proves that the private key to one of a specified set of public keys was used, without revealing which one. Monero assembles each spending transaction with a ring of decoys drawn from prior transaction outputs. The network verifies that exactly one output in the ring is being spent, without learning which one. The anonymity set is the ring size, currently sixteen, which means a transaction's true sender is hidden among sixteen candidates from the chain's history. The primitive has a cost. Every ring signature carries the decoys on-chain, and the resulting transaction size is larger than a Bitcoin transaction of comparable semantic content. The per-transaction storage overhead is the visible price of the privacy guarantee.

Ring signatures create an apparent problem: if no one knows which output in the ring is being spent, what stops the same output from being spent twice across different transactions, each time hiding behind a different ring? Monero resolves this with key images. Every spending transaction includes a key image, a value derived deterministically from the private key of the output being spent. The derivation is constructed so that the same output always produces the same key image, regardless of which decoys surround it in a given ring. Nodes maintain a global set of published key images and reject any transaction whose key image has already appeared. A double-spend attempt would reuse the private key of the real output, producing an identical key image, and would be rejected immediately. The ring can be shuffled arbitrarily; the key image is invariant. The construction lets Monero enforce one-spend-per-output without linking the key image to any specific ring member, because the image is derived from the real key but the ring signature proof does not reveal which ring member supplied it.

A ring of size sixteen is a meaningful improvement over Bitcoin's transparent chain, but it is bounded, and the bound is small compared to zero-knowledge constructions whose anonymity set can approach the entire output population. A single transaction with a ring of sixteen produces one-in-sixteen uncertainty for an adversary with no other information. A sequence of transactions by the same holder, analyzed jointly, reduces that uncertainty. Intersection attacks, in which the adversary observes several rings that all plausibly contain outputs from the same holder, narrow the candidate set multiplicatively across the sequence. The empirical literature on pre-RingCT Monero documented traceability of a substantial fraction of spends through closed-set chain-reaction analysis: if a ring contains only outputs already known to have been spent in other rings plus one unknown output, the unknown must be the real spend. The attack's reach on modern RingCT transactions is much narrower, but the underlying principle means that a ring's effective anonymity depends on the unknowns remaining unknown across the entire transaction graph.

Decoy selection is the operational axis that determines how close the effective anonymity set comes to the nominal sixteen. The first-spend heuristic is the concrete threat: empirical wallet behavior shows that users typically spend recent outputs, so an adversary who guesses that the most recent output in a ring is the real spend succeeds at a rate substantially above chance. Monero's wallet software counters this by drawing decoys from prior outputs according to a gamma distribution weighted toward older outputs, so that recent-output rings contain older decoys that blur the timing signal. The gamma distribution does not close every gap. Decoys drawn from outputs that turn out to have been spent in other rings reduce the effective anonymity; adversaries who contribute a large fraction of the on-chain output pool through their own transactions shape the decoy distribution available to subsequent users; and wallet implementations that deviate from the recommended selection algorithm produce transactions whose rings are distinguishable from the mainline population and therefore easier to analyze. The Monero development community has responded to each such finding with wallet-level decoy-selection improvements and with hardfork-level ring-size increases, but the underlying constraint remains: a sixteen-member ring cannot provide stronger privacy than the adversary's prior knowledge about which of the sixteen members are plausibly spendable.

A stealth address is a one-time address derived by the sender from the recipient's long-term address. The recipient publishes a single address but receives funds at a different, unlinkable on-chain address for every transaction. The construction uses elliptic-curve Diffie-Hellman between the sender's ephemeral key and the recipient's view key, so that only the recipient can scan the chain and identify incoming payments addressed to them. The chain contains no reusable anchor that a chain-analysis firm could cluster. Stealth addresses defeat the address-reuse heuristic structurally.

Ring Confidential Transactions, deployed on Monero in 2017, extend the ring signature to hide the amount alongside the sender. The construction uses Pedersen commitments to encrypt amounts, and range proofs (currently Bulletproofs and Bulletproofs+) to prove that each hidden amount is a non-negative integer whose sum balances the transaction's inputs and outputs. Without the range proofs, an attacker could create negative amounts and inflate supply; with them, the protocol preserves supply while hiding values. The per-transaction cost of this construction is substantial. A typical Monero transaction occupies roughly ten times the bytes of a Taproot Bitcoin spend, and verifying it costs roughly two orders of magnitude more CPU time on the same hardware, because every node must check the ring signature and the range proof for every input and output. Batching helps Bulletproofs verification within a block but does not help Concise Linkable Spontaneous Anonymous Group (CLSAG) signature verification, which scales linearly with ring size. The cost is paid by every participant, every block, forever.

Dandelion++, deployed on Monero in 2020, addresses the network-layer attack described in section 20.1. The protocol propagates a new transaction through a randomly chosen stem of relay nodes before broadcasting it to the wider network, so that an observer who captures the first broadcast cannot identify the originating IP address as easily as under naive gossip. The protection is probabilistic and limited against an adversary who controls many vantage points, but it raises the cost of the network-layer attack materially.

Monero's combined architecture makes on-chain clustering much harder than on Bitcoin. The properties hold against casual and moderately well-resourced adversaries. They do not hold against an adversary who can correlate off-chain information, such as an exchange's KYC record tied to a deposit address, nor against an adversary who runs a large fraction of the ring's decoys as their own prior outputs. The arms race between decoy selection and decoy analysis is live.

The protocol-level response in preparation is Full-Chain Membership Proofs. The FCMP and FCMP++ proposals, developed since 2023 primarily by Luke Parker, replace ring signatures with a zero-knowledge proof that the spent output belongs to the set of all spendable outputs on the chain. The anonymity set expands from sixteen to tens of millions, which is the entire output population, and the dependence on wallet-level decoy selection disappears along with the decoy-selection-attack class. The construction uses curve trees expressed over a Helios and Selene curve cycle to commit to the output set succinctly, and the proof size and verification cost remain feasible for consumer-scale wallets. A Monero hardfork enabling FCMP++ is in active preparation at the time of writing. When activated, it will be the largest upgrade to Monero's privacy architecture since RingCT, and it will close the specific class of attacks that exploit the ring's bounded size.^22^

Monero's privacy properties are hardcoded into the transaction format, not expressed through a programmable script, so the protocol has no general-purpose execution layer. Threshold multisig exists but is an off-chain coordination protocol between cosigners, not an on-chain scriptable condition. HTLCs, which require a hash preimage to be revealed on-chain at settlement, are incompatible with Monero's privacy model; XMR atomic swaps with Bitcoin are built on adaptor signatures instead, avoiding the hash-lock construction entirely. Timelocks exist in a limited form as a coarse block-height mechanism, but conditional timelocks of the kind Bitcoin's CSV and CLTV enable are absent. On-chain ZK verifiers, arbitrary multi-party contracts, and payment channel factories are outside the design space entirely. FCMP++ extends the anonymity set to the full output population but does not change any of this: it is a spending-proof upgrade, not a scripting upgrade. The tradeoff is deliberate. A fixed transaction format enforces privacy uniformly and eliminates the surface area through which a programmable layer could leak metadata. The cost is that Monero cannot host the second-layer payment channels, covenant schemes, or application-layer overlays that give Bitcoin's layered model its extensibility.

Zcash's Construction

Zcash takes a different path. Its base-layer ledger supports both transparent transactions and shielded transactions, with the shielded pool protected by zero-knowledge proofs. A fully shielded transaction reveals neither sender nor receiver nor amount nor any reusable linkage to other transactions; only a nullifier and a new commitment appear on-chain, and the proof accompanying the transaction certifies that the spender owned a valid coin in the shielded pool and has not spent it before. The cryptographic core is a zero-knowledge Succinct Non-Interactive Argument of Knowledge, or zk-SNARK, adapted for the specific statement the transaction must prove.

The protocol has gone through three generations of proof systems. The original Sprout pool, launched in 2016, used a SNARK construction that required a trusted setup ceremony whose compromise would have allowed undetectable counterfeiting. Sapling, activated in 2018, replaced the construction with a more efficient one and ran a second, multi-party ceremony to reduce the trusted-setup risk. Orchard, activated in the 2022 NU5 upgrade, uses the Halo 2 proof system, which eliminates the trusted setup requirement entirely through a recursive proof construction. The transition across these three generations illustrates an important property of privacy-at-the-base-layer designs: the cryptographic assumptions are not static. A privacy coin must plan for the replacement of its own core primitive, and the transitions must preserve value for existing holders without compromising the privacy of earlier transactions.

Zcash's optional-shielding model has consequences the Monero model does not have. Zcash transparent transactions behave like Bitcoin transactions and can be clustered with the same heuristics. Shielded transactions are private against all of those heuristics. The population that benefits from the privacy is the population that uses the shielded pool, and the shielded pool's usage rate has varied across the protocol's history. When the majority of the economic activity is transparent, an adversary can apply clustering to the transparent edges of shielded-to-transparent transfers and extract information about the shielded pool indirectly. The protocol designers have pursued wallet changes that make shielded transactions the default for new users, and those changes improve the pool's effective anonymity set, but the mixed-mode architecture is a structural feature that a pure-shielded design would not have.

The zk-SNARK construction that makes shielded transactions private also makes them expensive relative to Bitcoin. Sprout shielded transactions were several times larger than comparable Bitcoin transactions and required tens of seconds to prove on consumer hardware; every node on the network had to spend significant CPU verifying each one. The verification cost created a denial-of-service surface. In September 2018, shortly before Sapling activated, an attacker flooded the network with Sprout shielded transactions, bloating the mempool and forcing nodes to expend disproportionate computation per block. The attack slowed synchronization for full nodes materially and exposed a structural property of proof-based privacy: the same computation that certifies a transaction's validity is the mechanism through which an attacker can drain verifier resources. Sapling reduced both transaction size and proving time by over an order of magnitude and made the attack class less viable at Sapling's parameters, but the underlying dynamic remains. A shielded transaction costs more to verify than a transparent one, and any fee market that does not price verification compute accurately leaves room for cheap-to-create, expensive-to-verify spam. Orchard reduced verification cost further and supports batch verification, narrowing the gap, but the privacy premium in bandwidth and computation is a permanent feature of the architecture.^23^

Ethereum's Privacy Architecture

Ethereum's base layer is fully transparent. All transaction data is published to the chain and indexed by block explorers. The address graph is as visible as Bitcoin's, and the same clustering heuristics that chain-analysis firms apply to Bitcoin apply to Ethereum with equal or greater effect, because Ethereum's richer contract interactions create more linking signals, not fewer. The structural reason goes deeper than transparency alone. Bitcoin uses a UTXO model: each received coin is a discrete output at a specific address, and a wallet can generate a fresh address for every incoming payment, breaking the address-reuse heuristic at the wallet layer. Ethereum uses an account model: an address holds a running balance, and every inbound payment accumulates into that same account. Sharing an Ethereum address to receive funds is unavoidable, so every counterparty who sends to it learns the full balance and transaction history attached to that address. ERC-20 token transfers compound this: each token transfer from the same address links the account's ETH activity to its token activity across every contract it has ever called. The account model makes address reuse the base-layer payment mechanism. EIP-5564 stealth addresses offer a mitigation (a sender derives a one-time address from a recipient's public key so the recipient alone can identify incoming funds) but adoption remains marginal and the base-layer account structure is unchanged for users who do not generate stealth addresses for every inbound payment.

The "ZK rollups" that have made Ethereum a prominent topic in zero-knowledge proof discussions do not change this. ZK rollups (zkSync Era, StarkNet, Scroll, Polygon zkEVM) use cryptographic proofs to certify that the operator computed the state transition correctly; they publish all transaction data to Ethereum as calldata so that anyone can reconstruct the full L2 account history. The zero-knowledge proof answers whether the computation was correct, not who paid whom. The mechanics are covered in Chapter 15; the architectural point here is that a ZK rollup provides validity guarantees on a transparent ledger, not privacy on an opaque one. An outside observer who indexes the calldata knows every sender, receiver, and amount on every ZK rollup that follows this architecture.

Privacy on Ethereum is an application-layer property, achieved by smart contracts that implement shielded pools. The two deployed systems of note are Railgun and Aztec. Railgun operates as a set of immutable smart contracts on Ethereum mainnet, accepting deposits of ETH and ERC-20 tokens into a shielded pool where internal transfers use zero-knowledge proofs. An observer on-chain sees tokens enter and exit the Railgun contracts; internal transfers between shielded addresses are not visible, and deposits cannot be linked to specific withdrawals. The anonymity set for any given token is limited to that token's pool size, which creates the same weak-pool problem Zcash's optional-shielding model has: privacy depends on how many other users are shielding the same token. Aztec launched its Alpha mainnet in March 2026 as a private-by-default Layer 2. Its architecture is closer to Zcash's shielded model than to a ZK rollup: private state is represented as encrypted UTXO-style notes, private functions execute client-side, and only nullifiers and encrypted commitments appear on-chain. The Alpha network carried a disclosed critical vulnerability at launch, with a fix planned for a later release; the project positioned it as early-stage infrastructure with known security caveats. Aztec is the closest Ethereum analogue to a Zcash shielded pool, available as an opt-in L2 on top of an otherwise transparent base. Railgun's explicit positioning around association set compliance, following the framework Vitalik Buterin and co-authors described in a 2023 paper on Privacy Pools, reflects the enforcement environment that Tornado Cash's 2022 OFAC designation established. Chapter 13 covers the legal arc and the Van Loon ruling that vacated the protocol designation.^24^

The Comparative Analysis

The privacy guarantees Monero and Zcash provide are strong, and Ethereum's shielded pool systems provide real unlinkability within their pools. None of the core constructions in these systems have been broken. The architectural difference that matters is the breadth of assumptions and the size of the resistance surface, not privacy strength alone.

Bitcoin's base-layer consensus relies on well-understood primitives: elliptic-curve signatures on secp256k1, the SHA-256 hash function, and the proof-of-work security model built on them. The privacy layers above Bitcoin add primitives incrementally. CoinJoin adds only coordination; it introduces no new cryptographic assumption. PayJoin adds only a specific transaction-construction pattern. Lightning adds HTLC payments and the specific revocation-key dance, both built from the base primitives. Ark adds off-chain vTXOs with a shared UTXO construction; Spark adds off-chain balances via FROST threshold signing across statechain operators, each introducing no new on-chain consensus assumption. Chaumian ecash adds blind signatures, which rely on the same elliptic-curve assumptions. Shielded client-side validation introduces zero-knowledge proofs; those proofs rely on additional assumptions.

Monero and Zcash adopt the heavier cryptographic machinery as a condition of participation in the protocol at all. Every Monero transaction relies on ring signatures and Pedersen commitments and range proofs, and if any of those constructions failed, every transaction would be affected. Every Zcash shielded transaction relies on the zk-SNARK proof system in use at the time the transaction was made, and a failure in the proof system would be catastrophic. The Halo 2 transition reduced this risk by removing the trusted-setup assumption; it did not eliminate the dependence on the broader SNARK construction.

The cost asymmetry argument the book develops in Chapter 10 therefore runs differently for these protocols. Bitcoin keeps its base-layer resistance surface small and moves privacy into composable higher layers where failures are contained. Monero and Zcash build privacy into the base layer and accept a larger resistance surface in exchange. Both approaches are coherent. Which approach is more persuasive depends on whether the privacy guarantee at the protocol level matters more than the conservatism of the assumption set.

A second architectural difference affects what can be built on top of these base layers. Bitcoin Script supports multisig custody, timelocks, hash locks, HTLCs, Lightning's revocation-key construction, discreet log contracts, and the script commitments under which client-side validation operates. Monero's transaction format has no user-facing scripting, and Zcash's scripting remains narrower than Bitcoin's even after what Sapling and Orchard expose. The absence is not an oversight: expressive on-chain conditions reveal the structure the privacy layer is meant to hide, and the two protocols have consistently resolved the conflict in favor of privacy. The consequence is that Lightning-class payment channels, HTLC-routed cross-chain atomic swaps, and non-custodial escrow of the kind Bitcoin supports do not exist natively on Monero or Zcash. Privacy-preserving scaling on these chains happens at the base layer, with the verification-cost consequences already described, instead of in the composable higher layers that Bitcoin's limited-but-usable scripting enables. A third approach, distinct from both base-layer anonymity and Bitcoin's layered scripting, is the zero-knowledge smart-contract model that Amir Taaki's DarkFi has been developing: every contract is expressed as a ZK circuit whose proof is published on the chain, so arbitrary programmable logic runs without revealing the inputs or outputs to anyone verifying the proof. That model offers expressive contracts and privacy simultaneously, at the cost of a much heavier cryptographic assumption set and an early-stage implementation whose performance envelope is still being established.^25^

Regulators and exchanges have been delisting privacy coins for most of a decade, from the first Japanese withdrawals after the 2018 Coincheck hack through each successive wave of Travel Rule and MiCA enforcement. The underlying cause is structural: base-layer privacy conflicts with the Travel Rule and with the KYC edge the chain-analysis industry uses to anchor clusters, so any exchange that lists a privacy coin inherits a compliance problem that is cheaper to resolve by delisting. Bitcoin does not provoke the same conflict at the base layer, and privacy on Bitcoin is an achievement of higher layers built around a listed base currency. The same compliance pressure still reaches Bitcoin through a narrower channel. Chain-analysis firms flag coinjoin outputs as high risk, and major exchanges have rejected deposits traced to Wasabi or JoinMarket participations. Users who receive such outputs have had accounts frozen or funds held pending source-of-funds review, so Bitcoin users exercising the higher-layer privacy tools pay their costs at the on-ramp and off-ramp instead of at the protocol. The difference across the three regimes is architectural: Monero and Zcash fight for their base layer to be listed at all; Bitcoin fights over which higher-layer constructions downstream custodians will accept; Ethereum's application-layer privacy contracts occupy a middle position, subject to direct contract-address sanctions that Bitcoin's protocol-layer tools cannot receive, but not carrying the delisting pressure that base-layer privacy coins face.^26^

20.8 The Quantum Horizon for Bitcoin

Bitcoin's spending authorizations rest on the discrete-logarithm problem in the secp256k1 elliptic-curve group. Shor's algorithm solves that problem in polynomial time on a sufficiently powerful quantum computer, so any coin whose public key is visible on-chain becomes spendable by whoever runs the attack first. The threat is specific to the signature scheme; SHA-256 used for proof-of-work stays hard under Grover's quadratic speedup and is not at risk. The vulnerable population divides into two groups: coins at Pay-to-Public-Key addresses from Bitcoin's earliest years (a small transaction count but large value, including most of the supply attributed to Satoshi), and coins at reused or previously-spent Pay-to-Public-Key-Hash addresses whose public keys are already on-chain. Credible published estimates put roughly a quarter of the circulating supply in one of these categories. Coins held at addresses that have never revealed their public key are safe until the moment of spending, and spending itself becomes the window of attack.

The upgrade path is two steps, each a separate proposal. BIP-360 defines Pay-to-Merkle-Root, a SegWit version-2 output type with bc1z addresses. P2MR removes Taproot's key-path spend, leaving only the script-tree path, which closes the long-exposure vulnerability: an attacker who harvests a public key from an old P2MR output gains nothing, because the key path no longer exists. A second proposal, not yet written, will layer post-quantum signature opcodes onto the P2MR script tree to close the short-exposure window during mempool broadcast. Neither step is activated at the time of writing. The harder question is not cryptographic but political and economic: what to do with the roughly quarter of supply already at risk. Proposals range from mandatory migration within a deadline to permanent confiscation of unmoved coins at the moment a quantum attack becomes feasible. Every option distributes losses differently across holders, and the community has not resolved the question.

Signature size is the economic cost of the migration, and it runs directly into every layer above the base. A Schnorr signature is 64 bytes. FALCON, the compact lattice-based scheme NIST selected for ongoing standardization, produces 666 bytes at the 128-bit security level, a factor of ten over Schnorr. ML-DSA (FIPS 204, finalized August 2024) runs 2,420 to 4,595 bytes depending on security level. SLH-DSA (FIPS 205, finalized August 2024), the standardized hash-based family, runs 7,856 bytes in its smallest parameter set to nearly 50,000 bytes in its fastest. Kudinov and Nick of Blockstream Research showed in December 2025 that SPHINCS+ variants tuned to Bitcoin's requirements, reducing signatures per key and applying SPHINCS+C and PORS+FP optimizations, achieve meaningfully smaller signatures than standardized SLH-DSA while relying only on hash assumptions already present in Bitcoin's security model.^27^ Blockstream Research has taken this further with SHRINCS, a hybrid scheme pairing a stateful XMSS-derived path (approximately 1,092 bytes for a first spend, growing with subsequent spends from the same key) with a stateless fallback at 4,396 bytes, deployed experimentally on the Liquid sidechain. The direction of research is clear: Bitcoin-specific hash-based designs converge toward signatures in the low thousands of bytes, against Schnorr's 64, with verification costs close enough to Schnorr to remain node-accessible. Every privacy layer above the base inherits this cost. A Lightning channel open, a CoinJoin input, a Shielded CSV authorization: each carries the new signature, and the fee-market arithmetic of the post-quantum protocol is an open question the community must resolve before the threat arrives.^28^

Chapter Summary

Bitcoin's base layer is transparent by design, and a surveillance industry has built itself around address reuse, the common-input-ownership heuristic, change detection, network-layer observation, and KYC-anchored cluster identification. Privacy on Bitcoin is an architectural achievement built atop that base, with each layer introducing distinct tradeoffs along two axes: on-chain versus off-chain, and non-custodial versus custodial. Script primitives (multisig, timelocks, hash locks, HTLCs) enable layered construction without trusted intermediaries. CoinJoin and PayJoin improve on-chain privacy without changing consensus rules. CoinSwap severs the link between spent and received coins across separate ordinary-looking transactions with no on-chain mixing fingerprint; the construction is mainly theoretical on Bitcoin today, with Lightning serving as its off-chain production analogue. Lightning, Ark, and Spark move payments off-chain while preserving unilateral exit, at differing costs in operator visibility, liquidity management, and scripting capability. Custodial layers surrender unilateral exit for stronger privacy along a spectrum of increasing trust distribution: mixers conceal flows from outside observers but not from the operator, Chaumian ecash (Cashu and Fedimint) blinds the operator cryptographically at the cost of custody, and the Liquid federated sidechain distributes custody across a consortium while hiding amounts but leaving the transaction graph visible. Shielded client-side validation pushes the frontier further by publishing only opaque commitments the chain cannot read, in exchange for current research-stage maturity.

Monero and Zcash build privacy into the base layer, accepting a larger cryptographic assumption set and less programmability in exchange for default privacy. Monero's ring signatures hide the real input among sixteen decoys, key images prevent double-spend without revealing the real spender, stealth addresses break address-reuse clustering, and Ring Confidential Transactions hide amounts at the cost of transaction sizes roughly ten times a comparable Bitcoin spend. Decoy-selection attacks narrow the effective anonymity set below sixteen; FCMP++ replaces rings with a zero-knowledge proof over the entire output population, eliminating the attack class entirely, with a hardfork in preparation. Because privacy is hardcoded into the transaction format, Monero has no user-facing scripting: Lightning-class channels, HTLCs, and covenant schemes are absent by design. Zcash's zk-SNARKs shield sender, receiver, and amount together across three proof-system generations (Sprout 2016, Sapling 2018, Orchard with Halo 2 2022), with Halo 2 eliminating the trusted-setup assumption. The optional-shielding model means transparent and shielded transactions coexist: when most economic activity is transparent, chain analysis can extract information about the shielded pool from the edges of shielded-to-transparent transfers. Shielded transactions cost more to verify than transparent ones, a structural property that created a denial-of-service surface in 2018 when Sprout spam bloated the mempool; Sapling and Orchard reduced the gap without closing it.

Ethereum's base layer is as transparent as Bitcoin's, with an account model that makes address reuse the default payment mechanism: every counterparty who sends to an address learns its full balance and history. ZK rollups publish all transaction data to Ethereum as calldata; the zero-knowledge proof certifies correct computation on a transparent ledger, not privacy on an opaque one. Privacy on Ethereum is an application-layer property: Railgun implements shielded pools via immutable smart contracts on mainnet, and Aztec launched a private-by-default Alpha mainnet in March 2026 with a disclosed critical vulnerability and a fix planned for a later release. Both face a distinct enforcement channel: OFAC sanctioned Tornado Cash's contract addresses directly in 2022, a form of pressure structurally unavailable against Bitcoin's coordination-only privacy protocols. A decade of regulatory waves (Japan 2018, Bittrex 2021, MiCA-driven 2023–2024) has produced successive privacy-coin delistings because base-layer privacy conflicts with the Travel Rule at the protocol. Compliance pressure reaches Bitcoin privacy through a narrower channel: chain-analysis firms flag coinjoin outputs as high risk, and several exchanges have rejected deposits traced to Wasabi or JoinMarket, so users exercising higher-layer privacy tools pay their costs at the on-ramp and off-ramp.

The post-quantum horizon bounds every layer above Bitcoin's signature scheme. Shor's algorithm breaks secp256k1 on a sufficient quantum computer; BIP-360's Pay-to-Merkle-Root output type removes Taproot's key-path spend as a first step toward migration, with post-quantum signature opcodes to follow. ML-DSA (FIPS 204) runs 2,420 to 4,595 bytes per signature depending on security level; SLH-DSA (FIPS 205) runs 7,856 to 49,856 bytes across its parameter sets, with a size-speed tradeoff between small and fast variants; FALCON, whose FIPS standardization was still in progress at the time of writing, runs approximately 666 to 1,280 bytes. Kudinov and Nick (2025) show that SPHINCS+ variants optimized for Bitcoin achieve meaningful size reductions over standardized SLH-DSA while retaining hash-only security assumptions. Every figure is against Schnorr's 64 bytes, so the transition imposes fee pressure across every privacy layer that carries a spending authorization. No single layer provides complete financial privacy; each tool addresses specific metadata problems while leaving others unresolved, and operational discipline across layers, examined in Chapter 22, remains essential. The anonymous-communication foundations beneath these monetary layers (VPNs, Tor, mixnets) belong to Chapter 17.

---

Endnotes

^1^ Working tools for readers who want to apply what this chapter covers: Sparrow Wallet (sparrowwallet.com) is the strongest desktop Bitcoin wallet for coin control, label hygiene, and PayJoin/CoinJoin integration; JoinMarket (github.com/JoinMarket-Org/joinmarket-clientserver) remains an actively maintained CoinJoin implementation; Wasabi Wallet (wasabiwallet.io) ships WabiSabi-style coinjoins; Mempool.space, OXT (oxt.me), and KYCP (kycp.org) expose the same analytics that chain-analysis firms use, which is useful for learning what your transactions look like to them. For Lightning self-custody, Phoenix (phoenix.acinq.co), Zeus (zeusln.com), and Breez (breez.technology) ship mobile clients with different trust profiles; Core Lightning (corelightning.org) and LND (lightning.engineering) are the primary node implementations. On reading: the Bitcoin Wiki's "Privacy" page (en.bitcoin.it/wiki/Privacy) is the best-maintained encyclopedic reference, maintained by practitioners; Andy Greenberg, Tracers in the Dark (2022) is the definitive journalistic account of the surveillance industry this chapter describes; Bitcoin Optech (bitcoinops.org) publishes the best ongoing coverage of protocol-level developments. For Monero as the benchmark alternative privacy design, Sarang Noether and Brandon Goodell's Monero Research Lab reports (github.com/monero-project/research-lab) are worth reading.

^2^ Pieter Wuille, "BIP32: Hierarchical Deterministic Wallets" (2012); Marek Palatinus and Pavol Rusnák, "BIP44: Multi-Account Hierarchy for Deterministic Wallets" (2014); BIP84 and BIP86 extend the scheme for SegWit and Taproot outputs respectively. For a practitioner overview of reuse patterns and their prevalence, see the Bitcoin Wiki, "Address reuse," https://en.bitcoin.it/wiki/Address_reuse.

^3^ Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey M. Voelker, and Stefan Savage, "A Fistful of Bitcoins: Characterizing Payments Among Men with No Names," ACM Internet Measurement Conference (2013). The heuristic is also noted in Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System (2008), section 10. For the subsequent demonstration that reuse plus co-spending creates "super-clusters" linking many identities, see Martin Harrigan and Christoph Fretter, "The Unreasonable Effectiveness of Address Clustering," arXiv:1605.06369 (2016).

^4^ The change heuristics described here are catalogued on the Bitcoin Wiki, "Privacy," https://en.bitcoin.it/wiki/Privacy, drawing on Meiklejohn et al. (2013), Elli Androulaki et al., "Evaluating User Privacy in Bitcoin," Financial Cryptography (2013), and Jonas Nick, "Data-Driven De-Anonymization in Bitcoin," MSc thesis, ETH Zürich (2015). For a practitioner treatment of wallet fingerprinting, see 0xB10C's ongoing work at https://transactionfee.info.

^5^ 0xB10C, "LinkingLion: An Entity Linking Bitcoin Transactions to IPs?", observations post, https://b10c.me/ (2023), with follow-up update in 2024. For the earlier academic work on network-layer deanonymization, see Alex Biryukov, Dmitry Khovratovich, and Ivan Pustogarov, "Deanonymisation of Clients in Bitcoin P2P Network," ACM CCS (2014); and Philip Koshy, Diana Koshy, and Patrick McDaniel, "An Analysis of Anonymity in Bitcoin Using P2P Network Traffic," Financial Cryptography (2014). For Dandelion++: Giulia Fanti et al., "Dandelion++: Lightweight Cryptocurrency Networking with Formal Anonymity Guarantees," SIGMETRICS (2018).

^6^ For full-node wallet operation, Bitcoin Core at https://bitcoincore.org/ is the reference implementation; current storage footprint is approximately 700 GB with ~80–100 GB annual growth, initial sync 6–24 hours on consumer SSD. The canonical self-hosting guide is Jameson Lopp's resource collection at https://github.com/jlopp/civil-disobedience. Sparrow Wallet (https://sparrowwallet.com/) and Specter Desktop (https://specter.solutions/) are the two most common desktop wallets that pair with a local Bitcoin Core node. On the general architecture, see the Bitcoin Wiki "Privacy" page, https://en.bitcoin.it/wiki/Privacy, particularly §4.3 and §5.3 on wallet history retrieval.

^7^ BIP 157 (Olaoluwa Osuntokun, Alex Akselrod, and Jim Posen) and BIP 158 (Olaoluwa Osuntokun and Alex Akselrod), "Client Side Block Filtering" (2017), https://github.com/bitcoin/bips/blob/master/bip-0157.mediawiki and https://github.com/bitcoin/bips/blob/master/bip-0158.mediawiki. BIP 37 (Mike Hearn and Matt Corallo), "Connection Bloom filtering" (2012), https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki, disabled by default in Bitcoin Core via Matt Corallo's PR #16152 (merged 2019-07-19, shipped in 0.19.0). The privacy critique motivating the shift: Arthur Gervais, Ghassan O. Karame, Damian Gruber, and Srdjan Capkun, "On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin Clients," ACSAC '14 (2014), https://eprint.iacr.org/2014/763; Jonas Nick, "Privacy in BitcoinJ" (February 12, 2015), https://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/, empirically validates the attack. Bitcoin Development Kit (BDK) exposes the BIP 157/158 filter primitives to wallet developers at https://bitcoindevkit.org/, and the filter index is supported server-side by btcd (https://github.com/btcsuite/btcd) and by Bitcoin Core's opt-in blockfilterindex. Wasabi Wallet (https://wasabiwallet.io/) pioneered consumer-wallet client-side filtering with Wasabi 1.0 (August 2018) using a Wasabi-specific filter served from its own backend; Wasabi 2.6.0 (May 2025) added support for standard BIP 158 filters and direct Bitcoin Core node connection, release notes at https://github.com/WalletWasabi/WalletWasabi/releases/tag/v2.6.0. For self-hosted Electrum-protocol servers, ElectrumX (https://github.com/spesmilo/electrumx), electrs (Roman Zeyde, https://github.com/romanz/electrs), and Fulcrum (Calin Culianu, https://github.com/cculianu/Fulcrum) are the three standard implementations.

^8^ Stratum V2 specification at https://stratumprotocol.org/, with the Noise-framework encrypted transport and optional Job Declaration extension documented in the core specification. Stratum V2 production deployments: Braiins Pool (https://braiins.com/pool), DEMAND Pool (https://dmnd.work/), Public Pool (https://web.public-pool.io/). Reference implementation at https://github.com/stratum-mining/stratum. OCEAN Pool runs the parallel DATUM (Decentralized Alternative Templates for Universal Mining) protocol instead of Stratum V2; DATUM specification at https://ocean.xyz/docs/datum and source at https://github.com/OCEAN-xyz/datum_gateway. On Bitcoin's transaction-broadcast privacy via fresh-Tor-circuit-per-broadcast, see Wasabi Wallet's documentation at https://docs.wasabiwallet.io/ and Bitcoin Core's -onlynet=onion plus per-peer circuit isolation as described in the Tor configuration notes at https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md. For the Dandelion++ denial-of-service analysis that kept the proposal out of Bitcoin Core, see the Bitcoin Core PR discussion on the original Dandelion++ draft, referenced at https://github.com/bitcoin/bitcoin/issues/10054.

^9^ Gregory Maxwell, "CoinJoin: Bitcoin Privacy for the Real World," Bitcoin Forum post (2013). On WabiSabi, see Yuval Kogman, Max Hillebrand, Alex Wied, and Aviv Zohar, "WabiSabi: Centrally Coordinated CoinJoins with Variable Amounts," IACR ePrint 2021/206, https://eprint.iacr.org/2021/206; the WabiSabi protocol notes at https://github.com/WalletWasabi/WabiSabi/blob/master/protocol.md; and Bitcoin Optech Newsletter #102, "WabiSabi coordinated coinjoins with arbitrary output values," https://bitcoinops.org/en/newsletters/2020/06/17/#wabisabi-coordinated-coinjoins-with-arbitrary-output-values.

^10^ The unnecessary-input heuristic was applied specifically to PayJoin and P2EP detection by Adam Gibson (waxwing) and LaurentMT in a December 2018 GitHub gist that defined the UIH1 and UIH2 variants and provided the first empirical baseline against mainnet history; see https://gist.github.com/AdamISZ/4551b947789d3216bacfcb7af25e029e. Subsequent refinement to subset-sum form appeared in the same thread and was incorporated into the BTCPay PayJoin implementation through https://github.com/btcpayserver/btcpayserver/pull/4600. The academic treatment is Simin Ghesmati, Walid Fdhila, and Edgar Weippl, "Unnecessary Input Heuristics & PayJoin Transactions," IACR Cryptology ePrint Archive, Paper 2022/589 (2022), https://eprint.iacr.org/2022/589. The general unnecessary-input idea predates these and is curated in Chris Belcher's Bitcoin Wiki "Privacy" article at https://en.bitcoin.it/wiki/Privacy under the change-detection heuristics. BIP 78's own treatment of impacted heuristics, mixed input types, and fingerprint defenses is Nicolas Dorier, "BIP 78: A Simple Payjoin Proposal," https://github.com/bitcoin/bips/blob/master/bip-0078.mediawiki.

^11^ BIP 77 ("Async Payjoin") is Dan Gould and Yuval Kogman, https://github.com/bitcoin/bips/blob/master/bip-0077.md, first merged as a draft in May 2025. The reference implementation lives at https://github.com/payjoin/rust-payjoin, with the OHTTP relay component at https://github.com/payjoin/ohttp-relay and the production directory deployment at https://payjo.in/. Adoption status as of writing tracks the curated list at https://en.bitcoin.it/wiki/PayJoin_adoption: BTCPay Server, JoinMarket, Bull Bitcoin Mobile, and Cake Wallet ship both sender and receiver support; Wasabi, Sparrow, BlueWallet, Mutiny, and Sideshift ship send-only; Bitcoin Core has no native integration (tracking issue at https://github.com/bitcoin/bitcoin/issues/19148). The BIP 77 motivation section's own statement that "BIP 78's requirements for Payjoin Version 1 have proven to be an obstacle to adoption" is the most direct primary-source acknowledgment of the v1 infrastructure barrier.

^12^ Joseph Poon and Thaddeus Dryja, "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" (2016).

^13^ On Lightning privacy limitations, see Sergei Tikhomirov et al., "An Empirical Analysis of Privacy in the Lightning Network," Financial Cryptography (2021); Nishanth Chandran et al., "On the Difficulty of Hiding the Balance of Lightning Network Channels," IACR ePrint (2019). For a practitioner-oriented treatment of routing analysis, channel coinjoins, blinded paths, and trampoline routing as Lightning privacy improvements, see ben Carman, Evan Kaloudis, Max Hillebrand, Paul Miller, and Tony Giorgio, "Lightning Privacy Research," available at https://lightningprivacy.com and at https://github.com/BitcoinDevShop/lightning-privacy-research.

^14^ Matteo Romiti et al., "Cross-Layer Deanonymization Methods in the Lightning Protocol," Financial Cryptography (2021). The research showed clustering heuristics linking Lightning nodes to Bitcoin addresses through shared naming, hosting information, and on-chain interactions.

^15^ Burak Keçeli, "Ark: A Privacy-Preserving Layer 2 for Bitcoin" (2023), specification at https://arkdev.info/, with additional documentation at https://ark-protocol.org/. Arkade (https://arkadeos.com/) is the primary production implementation, operated by Ark Labs; its stack is at https://github.com/arkade-os. Second (https://second.tech/) is the other production implementation, operating an Ark server on Bitcoin mainnet with a parallel signet deployment; its wallet implementation (bark) is at https://gitlab.com/ark-bitcoin/bark. For comparison with the Lightning liquidity model the construction addresses, see Bastien Teinturier, "Ark and the Future of Bitcoin L2s," Bitcoin Optech newsletter coverage, 2023–2025, at https://bitcoinops.org/.

^16^ David Chaum, "Blind Signatures for Untraceable Payments," Advances in Cryptology: CRYPTO '82 (1983): 199-203. For Hal Finney's statement of the problem this section solves, see "Digital Cash & Privacy" (1993), https://nakamotoinstitute.org/library/digital-cash-and-privacy/, arguing that electronic payments create transaction dossiers unless spending is detached from account-level logs. Finney's "Protecting Privacy with Electronic Cash" (1993), https://nakamotoinstitute.org/library/protecting-privacy-with-electronic-cash/, gives the clearest period overview of the three-layer stack: public-key cryptography, anonymous messaging, and ecash.

^17^ For Cashu, see https://cashu.space/.

^18^ For Fedimint, see https://fedimint.org/.

^19^ Adam Back, Matt Corallo, Luke Dashjr, Mark Friedenbach, Gregory Maxwell, Andrew Miller, Andrew Poelstra, Jorge Timón, and Pieter Wuille, "Enabling Blockchain Innovations with Pegged Sidechains" (2014), https://blockstream.com/sidechains.pdf, is the foundational Liquid paper. Liquid Network documentation at https://liquid.net/, with the confidential-transactions construction documented at https://docs.liquid.net/docs/confidential-transactions-how-to and in Andrew Poelstra, "Confidential Assets" (2017), https://blockstream.com/bitcoin17-final41.pdf. The Liquid Federation membership and governance are described at https://liquid.net/about/; Elements, the open-source codebase, is at https://github.com/ElementsProject/elements.

^20^ Peter Todd, "Building Blocks of the State Machine Approach to Consensus" (2016), available at https://petertodd.org/2016/state-machine-consensus-building-blocks. The earlier proposal appears in Todd's November 2013 bitcoin-dev mailing list post on proof-of-publication consensus. For the RGB protocol's deployment of this approach, see the LNP/BP Standards Association's specifications at https://rgb.tech.

^21^ Jonas Nick, Liam Eagen, and Robin Linus, "Shielded CSV: Private and Efficient Client-Side Validation," IACR Cryptology ePrint Archive, Paper 2025/068 (January 2025), available at https://eprint.iacr.org/2025/068. Prototype implementation at https://github.com/ShieldedCSV/ShieldedCSV.

^22^ Monero encodes three privacy primitives at the base layer: ring signatures (Rivest-Shamir-Tauman 2001), stealth addresses, and Ring Confidential Transactions with Bulletproofs range proofs; the sixteen-member ring is the bounded anonymity set that decoy-selection attacks exploit and that Full-Chain Membership Proofs (FCMP++) are designed to replace with chain-wide anonymity. Monero project, https://www.getmonero.org/. Source at https://github.com/monero-project/monero. Monero Research Lab technical reports, https://github.com/monero-project/research-lab. Original ring signatures: Ronald L. Rivest, Adi Shamir, and Yael Tauman, "How to Leak a Secret," ASIACRYPT 2001. RingCT: Shen Noether, "Ring Confidential Transactions," IACR ePrint 2015/1098 (2015). Bulletproofs: Benedikt Bünz, Jonathan Bootle, Dan Boneh et al., "Bulletproofs: Short Proofs for Confidential Transactions and More," IEEE Symposium on Security and Privacy (2018). Bulletproofs+: Heewon Chung, Kyoohyung Han, Chanyang Ju et al., "Bulletproofs+: Shorter Proofs for Privacy-Enhanced Distributed Ledger," IACR ePrint 2020/735. Dandelion++: Giulia Fanti, Shaileshh Bojja Venkatakrishnan et al., "Dandelion++: Lightweight Cryptocurrency Networking with Formal Anonymity Guarantees," ACM SIGMETRICS (2018). On the empirical traceability of pre-RingCT Monero and the closed-set chain-reaction attack, Malte Möser, Kyle Soska, Ethan Heilman et al., "An Empirical Analysis of Traceability in the Monero Blockchain," Proceedings on Privacy Enhancing Technologies 2018, no. 3 (2018): 143–163, and Andrew Miller, Malte Möser, Kevin Lee, and Arvind Narayanan, "An Empirical Analysis of Linkability in the Monero Blockchain," IACR ePrint 2017/338, remain the standard references. On decoy-selection analyses and wallet-level responses, see Justin Ehrenhofer's survey work and the Monero Research Lab bulletins at https://www.getmonero.org/resources/research-lab/. On Full-Chain Membership Proofs, Luke Parker (kayabaNerve), "FCMP++: Full-Chain Membership Proofs for Monero" (2024), https://www.getmonero.org/2024/04/27/fcmps.html, with specification and implementation at https://github.com/kayabaNerve/fcmp-plus-plus. On transaction-size and throughput comparison, see the Monero Research Lab "Empirical Results" bulletins and the broader comparative analysis in Harry Halpin and Ania Piotrowska, "Forensic Analysis of Privacy Coins" (2020), as well as ongoing per-block statistics at https://moneroblocks.info/ and https://mempool.space/ for the Bitcoin counterpart.

^23^ On the Zcash transaction size and verification cost comparison, and the September 2018 Sprout spam attack: the attack is documented in Electric Coin Company retrospectives and Zcash community forums from September–October 2018; the bloated mempool and node slowdown are referenced in ECC's Sapling launch communications as part of the motivation for Sapling's proof-system redesign. On Sapling's efficiency improvements over Sprout, see Sean Bowe, Jack Grigg, Ian Miers et al., "Sapling," Electric Coin Company technical specification (2018), https://github.com/zcash/sapling-spec, and the Sapling protocol specification at https://zips.z.cash/protocol/sapling.pdf. On Orchard batch verification, see the Zcash protocol specification at https://zips.z.cash/protocol/protocol.pdf §5.4.

^24^ On Ethereum's privacy architecture: Railgun protocol documentation at https://railgun.org/; Railgun smart contracts at https://github.com/Railgun-Community/. Aztec Network documentation at https://docs.aztec.network/; Aztec source at https://github.com/AztecProtocol/aztec-packages. Aztec launched its Alpha mainnet March 31, 2026; the launch announcement is at https://aztec.network/blog/announcing-the-alpha-network. A critical vulnerability in the Alpha v4 proving system was disclosed March 27, 2026, with a fix planned for a v5 release in July 2026; see https://aztec.network/blog/critical-vulnerability-in-alpha-v4. Aztec's predecessor product, Aztec Connect, stopped accepting deposits March 21, 2023, and shut down its sequencer March 31, 2024; all code is open-sourced. On the validity-vs-privacy distinction for ZK rollups, the ethereum.org documentation on ZK rollups states explicitly that rollups publish state data for every transaction processed off-chain to Ethereum, enabling independent reconstruction of rollup state; see https://ethereum.org/en/developers/docs/scaling/zk-rollups/. On Tornado Cash: U.S. Department of Treasury, OFAC designation of Tornado Cash, August 8, 2022, https://home.treasury.gov/news/press-releases/jy0916. Alexey Pertsev convicted in the Netherlands, May 2024. On Privacy Pools: Vitalik Buterin, Jacob Illum, Matthias Nadler, Fabian Schär, and Ameen Soleimani, "Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium," SSRN 4563364 (2023), https://ssrn.com/abstract=4563364.

^25^ DarkFi is Amir Taaki's zero-knowledge smart-contract platform. Every contract is compiled to a zero-knowledge circuit, and transactions carry proofs instead of readable input/output data, so arbitrary programmable logic executes under encryption. Project site and documentation at https://dark.fi/. Source at https://codeberg.org/darkrenaissance/darkfi. On Taaki's broader work in the cypherpunk tradition, see Carl Miller, "The Death of the Gods: The New Global Power Grab" (Windmill Books, 2018), ch. 8, and interviews collected at https://agorism.dev/.

^26^ Zcash applies zk-SNARKs to shielded transactions across three proof-system generations (Sprout 2016, Sapling 2018, Orchard/Halo 2 2022); privacy-coin exchange delistings go back to Japan's 2018 FSA pressure, extended through Bittrex's January 2021 U.S. delisting, and accelerated in 2023–2024 as MiCA took shape; Monero and Zcash both lack the base-layer scripting that enables Bitcoin's Lightning and HTLC-based Layer 2 stack. Zcash project, https://z.cash/. Electric Coin Company, https://z.cash/. Zcash protocol specification at https://zips.z.cash/protocol/protocol.pdf. On the NU5 upgrade and Halo 2, see https://z.cash/blog/explaining-halo-2/. Halo 2 paper: Sean Bowe, Jack Grigg, and Daira Hopwood, "Recursive Proof Composition without a Trusted Setup," IACR ePrint 2019/1021. On the trusted-setup ceremonies, see Matthew Green, "Zcash Counterfeiting Vulnerability Successfully Remediated" (2019), https://z.cash/blog/zcash-counterfeiting-vulnerability-successfully-remediated/. On the scripting comparison, see Jameson Lopp's overview of Bitcoin Script primitives at https://www.lopp.net/bitcoin-information.html and the Monero and Zcash protocol specifications linked above; for the academic framing of the privacy-vs-programmability tradeoff, see Andrew Poelstra, "Confidential Assets" (2017), https://blockstream.com/bitcoin17-final41.pdf, which analyzes the structural conflict. On the history of privacy-coin exchange delistings: Japan's 2018 FSA pressure and the Coincheck response are covered in Reuters reporting from June–September 2018; ShapeShift's 2018 KYC transition and associated delistings at https://shapeshift.com/; Bittrex U.S. delisting announcement (January 2021) at https://bittrex.zendesk.com/; Kraken EEA Monero delisting (effective February 2024) at https://support.kraken.com/; Binance Monero delisting announcement (February 2024) at https://www.binance.com/en/support/announcement/; OKX privacy-coin delistings (late 2023–early 2024) tracked in CoinDesk and The Block coverage at https://www.coindesk.com/ and https://www.theblock.co/. On the Travel Rule's interaction with privacy coins, FATF Recommendation 16 guidance at https://www.fatf-gafi.org/.

^27^ Mikhail Kudinov and Jonas Nick, "Hash-based Signature Schemes for Bitcoin," IACR Cryptology ePrint Archive, Paper 2025/2203 (December 2025), https://eprint.iacr.org/2025/2203. The paper argues that hash-based signature schemes are preferable for Bitcoin over lattice-based schemes (ML-DSA) because their security relies solely on hash-function assumptions already present in Bitcoin's design. It applies recent optimizations (SPHINCS+C, TL-WOTS-TW, and PORS+FP) to produce variants with substantially smaller signatures than standardized SLH-DSA, and analyzes constraints specific to Bitcoin including key derivation, multi-signatures, and threshold signatures. Kudinov is at Blockstream Research; Nick is a Bitcoin protocol developer also at Blockstream Research and a co-author of the MuSig2 and BIP-327 work. For the SHRINCS scheme: C++ implementation at https://github.com/BlockstreamResearch/shrincs-cpp; Simplicity verifier at https://github.com/BlockstreamResearch/shrincs-simplicity-verifier; specification at https://github.com/BlockstreamResearch/shrincs-specification; parameter exploration scripts at https://github.com/BlockstreamResearch/SPHINCS-Parameters. The performance figures cited (1,092 bytes stateful at q=1, 4,396 bytes stateless) are from the SHRINCS-L Liquid performance report in the shrincs-cpp repository, benchmarked on an Intel Core i5 with 16 GB RAM; live Liquid transactions are linked in that report.

^29^ Chainalysis, founded 2014, https://www.chainalysis.com/. Elliptic, founded 2013, https://www.elliptic.co/. TRM Labs, founded 2018, https://www.trmlabs.com/. Mastercard's CipherTrace, acquired by Mastercard 2021, https://ciphertrace.com/. Each vendor maintains a proprietary labeled-address database assembled from exchange partnerships, subpoenas, deposit-address harvesting, and open-source intelligence; the commercial contracts through which exchange KYC data flows to these vendors are generally not public. For independent academic analysis of how the labeling ecosystem works, see Kimberly Easton, Malte Möser, and Tyler Moore, "An Analysis of the Cryptocurrency Industry's Transaction Monitoring Ecosystem," Financial Cryptography (2022).

^30^ United States v. Roman Sterlingov, No. 21-cr-00399 (D.D.C.). Sterlingov was arrested in April 2021 and convicted by jury in March 2024 on money-laundering conspiracy charges arising from his alleged operation of Bitcoin Fog, a centralized mixing service active from 2011 to 2021. The trial became a high-profile test case for chain-analysis attribution: the government relied heavily on Chainalysis Reactor testimony, and defense expert Elizabeth Bisbee challenged the methodology's reproducibility and peer-review status. The court admitted the evidence; the verdict is under appeal. For the trial record and expert testimony transcripts, see the PACER docket for 1:21-cr-00399. Journalistic coverage: Andy Greenberg, Wired, March 12, 2024, "The Controversial Evidence That Convicted Bitcoin Fog's Alleged Operator."

^31^ Financial Action Task Force (FATF), "Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers" (June 2019), https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-rba-virtual-assets-2019.html. The Travel Rule requirement (FATF Recommendation 16 applied to VASPs) mandates that originator and beneficiary identifying information travel with transfers above USD/EUR 1,000. FATF, "Updated Guidance for a Risk-Based Approach: Virtual Assets and VASPs" (October 2021), https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-rba-virtual-assets-2021.html. National rollout varied: FinCEN applied existing BSA rules; the EU's Transfer of Funds Regulation (TFR) extended Travel Rule to all crypto transfers regardless of amount from December 2024 under MiCA's companion regulation. For a compliance-industry survey of national implementation status, see CipherTrace, "FATF Travel Rule Global Implementation" (2023), https://ciphertrace.com/.

^32^ BIP 341 (Taproot), Pieter Wuille, Jonas Nick, and Anthony Towns, "Taproot: SegWit version 1 spending rules" (2020), https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki. Activated at block 709,632, November 14, 2021. BIP 342 (Tapscript), same authors, https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki. BIP 340 (Schnorr signatures), Pieter Wuille, Jonas Nick, and Tim Ruffing, https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki. The privacy analysis of the key-path vs. script-path spend is in BIP 341 §Motivation; the point that unused script branches remain unpublished is central to the design. For the activation history (Speedy Trial, signaling, lock-in), see Bitcoin Optech Newsletter #139 and #157, https://bitcoinops.org/.

^33^ MuSig2: Jonas Nick, Tim Ruffing, and Yannick Seurin, "MuSig2: Simple Two-Round Schnorr Multi-Signatures," CRYPTO 2021, IACR ePrint 2020/1261, https://eprint.iacr.org/2020/1261. Standardized as BIP 327: Jonas Nick, Tim Ruffing, Yannick Seurin, and Elliott Jin, "MuSig2: Schnorr Multi-Signature Protocol," https://github.com/bitcoin/bips/blob/master/bip-0327.mediawiki. FROST (Flexible Round-Optimized Schnorr Threshold signatures): Chelsea Komlo and Ian Goldberg, "FROST: Flexible Round-Optimized Schnorr Threshold Signatures," Selected Areas in Cryptography (2020), IACR ePrint 2020/852, https://eprint.iacr.org/2020/852. FROST is the basis of Spark's signing protocol and of several Bitcoin wallet threshold-custody implementations; it is also the signature scheme underlying FCMP++ leaf proofs in Monero. For threshold ECDSA as the pre-Schnorr alternative, see Rosario Gennaro and Steven Goldfeder, "Fast Multiparty Threshold ECDSA with Fast Trustless Setup," ACM CCS 2018.

^34^ JoinMarket, available at https://github.com/JoinMarket-Org/joinmarket-clientserver. Originally developed by Chris Belcher and Adam Gibson (waxwing); Adam Gibson's design essays, including "JoinMarket: Rethinking Coinjoin" (2017), explain the market-maker/taker model and the privacy rationale. JoinMarket's Orderbook (https://joinmarket.me/ob/) shows active maker liquidity in real time. For the PayJoin-inside-JoinMarket extension (P2EP), see Adam Gibson's blog at https://reyify.com/blog/. The protocol's resistance to coordinator takedown stems from the fact that each taker coordinates its own round directly with chosen makers over an encrypted messaging layer (currently IRC and Tor hidden services), so there is no single coordinator server to subpoena or block.

^35^ Tier Nolan, "Alt chains and atomic transfers," Bitcoin Forum, May 2013, https://bitcointalk.org/index.php?topic=193281.msg2003765. This post is the earliest documented proposal for atomic cross-chain swaps using hash-timelock contracts. The same-chain CoinSwap application was developed subsequently; for the earliest formal treatment of CoinSwap as an on-chain privacy tool, see Greg Maxwell's discussion in the CoinJoin thread (2013) and Chris Belcher's "CoinSwap: Transaction graph disjoint trustless trading" proposal (2020), https://gist.github.com/chris-belcher/9144bd57a91c194e332fb5ca371d0964.

^36^ Spark protocol: Buildonspark, "Spark: A Bitcoin Statechain Protocol," specification at https://docs.spark.money/ and https://github.com/buildonspark/spark. Spark extends the statechain model originated by Ruben Somsen: Ruben Somsen, "Statechains: Non-custodial Off-chain Bitcoin Transfer," Bitcoin Optech Newsletter #91 (2020), and the full proposal at https://github.com/RubenSomsen/rubensomsen.github.io/blob/master/img/statechains.pdf. The FROST threshold extension across multiple Signing Operators is Spark's key departure from the original single-operator statechain design. For Somsen's original statechain proposal, see also the bitcoin-dev mailing list thread from March 2020.

^37^ Cashu protocol specification: https://github.com/cashubtc/nuts (Cashu NUTs - Notation, Usage, and Terminology). Reference mint implementation: Nutshell, https://github.com/cashubtc/nutshell. Reference wallet: Cashu.me (web), https://cashu.me. The Cashu protocol was designed by Calle (https://github.com/callebtc) drawing directly on Chaum's 1982 blind-signature construction. For a technical walkthrough of the mint/token/redemption cycle and the operator-blindness property, see the Cashu documentation at https://docs.cashu.space/ and Calle's "Cashu: A Chaumian Ecash Wallet and Mint with Bitcoin Lightning" writeup, https://github.com/cashubtc/cashu/blob/main/docs/WHITEPAPER.md.

^38^ The zkSNACKs coordinator (wasabiwallet.io) announced on June 1, 2024 that it would stop coordinating CoinJoin transactions for U.S.-linked UTXOs following Department of Justice actions against Samourai Wallet (April 2024). The coordinator fully ceased operation on June 1, 2024. On the Samourai Wallet prosecution: United States v. Keonne Rodriguez and William Lonergan Hill, No. 24-cr-00242 (S.D.N.Y.), indictment unsealed April 24, 2024, charging money laundering conspiracy and operating an unlicensed money transmitting business through Samourai's Whirlpool CoinJoin and Ricochet features. The alternative coordinators that emerged include WabiSabi-compatible coordinators operated by BTCPay Server (https://btcpayserver.org/) and independent operators discoverable through Wasabi's coordinator-list mechanism; see https://wasabiwallet.io/swagger/index.html for the coordinator API. The WabiSabi protocol specification is open at https://github.com/WalletWasabi/WabiSabi.

^28^ Shor's algorithm breaks secp256k1 signatures on a sufficient quantum computer, placing Bitcoin funds at reused addresses and P2PK outputs at risk; BIP-360's Pay-to-Merkle-Root (P2MR) output type defends against long-exposure attacks by removing Taproot's key-path spend, with post-quantum signatures layered on top in a separate future proposal. BIP-360, version 0.11.0 (February 2026), "Pay-to-Merkle-Root," Hunter Beast, Ethan Heilman, and Isabel Foxen Duke, https://github.com/bitcoin/bips/blob/master/bip-0360.mediawiki. The BIP was previously named P2QRH (v0.1, September 2024) and P2TSH (v0.10, September 2025) before settling on P2MR; the changelog in the BIP itself documents this history. On the distinction between long-exposure and short-exposure attacks and the rationale for separating the P2MR output type from the post-quantum signature work, see the BIP-360 motivation and glossary sections. NIST post-quantum signature standards (all finalized August 13, 2024): FIPS 204 (ML-DSA, based on Dilithium), https://csrc.nist.gov/pubs/fips/204/final; signature sizes: ML-DSA-44 = 2,420 bytes, ML-DSA-65 = 3,293 bytes, ML-DSA-87 = 4,595 bytes (FIPS 204 Table 1). FIPS 205 (SLH-DSA, based on SPHINCS+), https://csrc.nist.gov/pubs/fips/205/final; signature sizes range from 7,856 bytes (SLH-DSA-SHA2-128s, small/slow) to 49,856 bytes (SLH-DSA-SHA2-256f, large/fast) across the twelve parameter sets (FIPS 205 Table 2). FALCON (the compact lattice-based scheme, Falcon-512 approximately 666 bytes, Falcon-1024 approximately 1,280 bytes) was selected by NIST for ongoing standardization; as of the time of writing, no FIPS number had been assigned and the standard had not been published. NIST post-quantum cryptography project overview: https://csrc.nist.gov/projects/post-quantum-cryptography. On the current consensus timeline for a cryptographically relevant quantum computer capable of breaking secp256k1: the dominant estimate in the research community and among security agencies is 10–20 years, with the NSA's CNSA 2.0 suite mandating transitions by 2030–2035; a 2024 paper by Alice & Bob (https://alice-bob.com/blog/computing-256-bit-elliptic-curve-logarithm-in-9-hours-with-126133-cat-qubits/) substantially reduced prior resource estimates, calculating that 126,133 cat qubits could in principle break ECC-256 in 9 hours, though no machine near this qubit count exists. For ongoing bitcoin-dev and DelvingBitcoin discussion of quantum migration, see https://gnusha.org/pi/bitcoindev/ and https://delvingbitcoin.org/. On the fraction of Bitcoin supply at quantum risk, see Deloitte, "Quantum Computers and the Bitcoin Blockchain" (2021). Bitcoin Optech post-quantum coverage at https://bitcoinops.org/.

---

<- **Previous: Bitcoin as Sound and Resistant Money** |

-> Next: Decentralized Social Infrastructure | Article

The Praxeology of Privacy -- third edition. New chapters publish daily at 1600 UTC.