BIP 158

BIP-158 defines compact block filters - a privacy-preserving way for SPV clients to determine which blocks contain transactions relevant to them. Together with the partner spec BIP-157 (the network protocol for fetching them), it's the modern replacement for the older BIP-37 Bloom-filter approach used by Merkle blocks.

The privacy problem with Bloom filters: a lightweight client sends its filter (containing patterns derived from its addresses) to a full node. The node can probabilistically reverse-engineer which addresses the client cares about. This was widely understood as a meaningful privacy leak by the mid-2010s.

How BIP-158 fixes it: invert the direction. The full node computes a deterministic filter per block, encoding which scripts the block touched. The light client downloads each block's filter and checks it locally for matches against its own addresses. The full node has no idea what the client is looking for.

The filters use Golomb-Rice coding (a compact representation) plus a SipHash variant for queries. Typical filter size is ~20 KB per block - about 1 GB for a year of blocks and roughly 13 GB for the whole chain by 2026, vs hundreds of GB for downloading all the blocks themselves.

This is sometimes called the "Neutrino protocol" after the original implementation by Lightning Labs, which integrated it into LND and the Neutrino client. It is one of several ways a light wallet can sync: LND's Neutrino mode and a few self-custodial mobile wallets use it, while others query Electrum-style servers instead.

The tradeoff vs running a full node is unchanged: you save storage and bandwidth, you give up direct consensus enforcement (you follow the chain with the most proof of work without checking its rules yourself, and you need at least one honest peer to get the correct filters). For a self-custody mobile wallet, BIP-158 is a strong privacy-aware compromise.