Pruned nodes and light clients (SPV)

Wonder

1. How does a node validate the entire history of Bitcoin without storing every block forever?
2. What specific cryptographic mechanism allows a smartphone wallet to verify its balance without downloading hundreds of gigabytes of data?
3. Why did the original privacy-preserving filters for light wallets leak user identities, and how was that flaw fixed?

Explore

1. Full validation and full storage are separable. Every validating node must process every block once to build the current set of unspent outputs, but it need not keep old blocks afterwards. Some clients go further and skip validation entirely, checking only that transactions are included in blocks with enough proof of work. The choices trade disk space, bandwidth and privacy against independence.
2. A pruned node performs this same initial validation of every block from genesis but subsequently deletes old block data to save disk space. The `prune` setting in Bitcoin Core retains at least 550 MB of recent blocks while discarding older ones once verified. It remains a full validator, capable of enforcing consensus rules and protecting its owner’s wallet with independent truth. However, it can no longer serve historical block data to other peers or support features requiring deep chain lookups like `txindex`.
3. Light clients, or SPV nodes, take a different approach by not validating the full ruleset. They download only block headers, which contain the Merkle root of all transactions in that block. To verify a specific transaction’s inclusion, the client requests a Merkle proof from a peer and checks it against the header’s root. This relies on the assumption that the chain with the most cumulative work is valid, trading independent rule-enforcement for drastic reductions in storage and bandwidth requirements.
4. Early SPV implementations used BIP37 Bloom filters to let wallets request only relevant transactions from peers. The wallet sent a filter describing its addresses; peers would scan their mempool and send matching transactions. This design leaked privacy: by observing the filters, a malicious peer could deduce which addresses belonged to the user and track their activity. Bitcoin Core stopped serving Bloom filters by default in 2019 (version 0.19).
5. Compact Block Filters (BIP157/158) reversed this flow to restore privacy. Instead of the wallet revealing its addresses, full nodes publish a compact filter for each block; the client downloads these filters and tests them locally against its own keys. When a filter matches, the client downloads the whole block, because requesting a single transaction would reveal it to the peer. This prevents peers from knowing which addresses the wallet monitors, significantly improving user privacy while maintaining efficient synchronization.
6. Many mobile wallets rely on a third-party server, for example an Electrum server, for data, while checking Merkle proofs against block headers themselves. The trade-off is clear: convenience and low resource usage versus independent verification and privacy. A user running a pruned node retains full validation capability but limited historical serving; an SPV wallet retains a minimal footprint but relies on peers to show it every relevant transaction and assumes, without checking, that the most-work chain is valid.

Key facts

Exercise nine, six, three, one

Fact check

Dates, figures and claims checked against the published sources listed below.

• Satoshi Nakamoto, 'Bitcoin: A Peer-to-Peer Electronic Cash System' (2008), Section 8
• BIP37: Connection Bloom filtering
• BIP157: Client Side Block Filtering
• BIP158: Compact Block Filters for Light Clients
• Bitcoin Core release notes 0.11.0 (pruning)
• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 10