Overview
Compact Block Filters, specified in BIP157 and BIP158, are a privacy-preserving method for lightweight Bitcoin clients to determine which blocks contain transactions relevant to them. Unlike the older Bloom filter approach (BIP37) used by traditional SPV clients, compact block filters are created by full nodes and downloaded by clients, who then perform all matching locally. This architectural inversion fundamentally changes the privacy model: the server never learns which addresses or transactions the client is interested in.
The protocol is sometimes referred to by its implementation name "Neutrino," originally developed for the lnd Lightning Network client. It has become the preferred light client protocol for privacy-conscious Bitcoin wallets and Lightning applications that cannot run a full node.
How It Works
BIP37 Bloom Filters (OLD — privacy leak):
┌────────┐ "Here are my addresses ┌────────────┐
│ Light │ (obfuscated in a bloom │ Full Node │
│ Client │ filter)" │ │
│ │ ──────────────────────→ │ Learns │
│ │ │ which addrs│
│ │ "Here are matching txs" │ client │
│ │ ◀────────────────────── │ cares about│
└────────┘ └────────────┘
BIP157/158 Compact Block Filters (NEW — private):
┌────────┐ "Give me the filter ┌────────────┐
│ Light │ for block 800,000" │ Full Node │
│ Client │ ──────────────────────→ │ │
│ │ │ Learns │
│ │ "Here is the filter" │ NOTHING │
│ │ ◀────────────────────── │ about │
│ │ │ client │
│ Client │ (checks filter locally) └────────────┘
│ finds │
│ match │ "Give me full block
│ │ 800,000"
│ │ ──────────────────────→ (downloads
│ │ ◀────────────────────── full block,
└────────┘ same as any
other peer)
Each block's compact filter is a compressed representation of all the scriptPubKeys (output scripts) and spent scriptPubKeys (input scripts) in that block, encoded using Golomb-Rice coding. The resulting filter is typically 15-25 KB per block, roughly 1/100th the size of the full block. A client downloads filters for every block, tests them locally against its own addresses, and only downloads the full block data when the filter indicates a potential match.
The Privacy Advantage
With BIP37 Bloom filters, clients send a probabilistic data structure to the server that encodes which addresses they care about. Research has shown that servers can extract substantial information from these filters, particularly across multiple requests. Even with false positives added, the privacy leakage is significant.
Compact block filters eliminate this entirely. The full node serves the same filter to every client that asks for it, learning nothing about which particular addresses or transactions the client is interested in. The filter is deterministic: every node generates the same filter for the same block, so clients can even cross-verify filters from multiple sources.
Trade-offs
The compact block filter approach involves trade-offs compared to both full nodes and traditional SPV:
- Bandwidth: Clients must download filters for every block (roughly 4-5 GB for the entire chain), significantly more than BIP37 but far less than the full blockchain
- False positives: Filters have a configurable false positive rate (approximately 1 in 784,931 by default). When a false positive occurs, the client downloads a full block unnecessarily
- No full validation: Like all light client approaches, compact block filters do not validate consensus rules beyond proof-of-work. Clients trust that the longest chain is valid
- Server load: Full nodes must compute and store filters, adding modest disk and CPU requirements
Adoption
Compact block filters are supported by Bitcoin Core (serving filters since version 0.21.0), lnd, Wasabi Wallet, and several other implementations. The protocol has become the standard approach for Lightning Network mobile wallets that need to verify channel states without running a full node. For users who cannot run their own full node, compact block filters represent the best available compromise between sovereignty and resource requirements.
Related Concepts
- Simplified Payment Verification — The original light client concept from the Bitcoin whitepaper
- Full Node — The gold standard for verification that compact block filters approximate
- Pruned Node — Another resource-saving approach, but with full validation
- BIP — The proposal process through which BIP157 and BIP158 were standardized
- Node — The network participants that serve compact block filters