Bloom Filter (BIP37)

Bloom Filter (BIP37) refers to connection Bloom filtering, the first widely deployed way for a Simplified Payment Verification (SPV) wallet to download only the transactions relevant to it instead of full blocks. A Bloom filter is a compact probabilistic set structure: it can say "definitely not in the set" or "probably in the set," never storing the items themselves. The client loads its wallet's addresses and outputs into the filter, sends it to a full node, and the node returns matching transactions plus some extras dictated by a tunable false-positive rate.

The protocol messages

A client establishes a filter with filterload (specifying the bit field, hash-function count, and a randomizing tweak), extends it with filteradd, and clears it with filterclear. The serving node replies with a merkleblock message: the block header, the hashes of matching transactions, and a partial Merkle tree proving those transactions belong to the block, with the matching transactions sent separately. The Merkle proof is what lets a light client verify inclusion against nothing more than the 80-byte header chain — the same Merkle root commitment miners build into every block. In principle the false-positive rate doubles as a privacy dial: the more junk the filter matches, the less certain a node is about which transactions are really yours.

Why it fell out of favor

The privacy model turned out to be fundamentally weak. The client reveals its filter — and hence a fingerprint of its own addresses — directly to the peer it queries; research showed that even with generous false-positive rates a peer can often recover a wallet's address set outright, especially by intersecting the filters a client sends across sessions, and link it to the client's IP address. The design also inverted Bitcoin's usual cost logic: a cheap client request forces the serving node to scan and filter entire blocks, an asymmetry that invites denial-of-service abuse. Because of both problems, Bitcoin Core has disabled serving BIP37 filters by default since version 0.19, and the ecosystem moved to a model that flips the roles: with compact block filters (BIP158), nodes publish one deterministic filter per block and the client checks it locally, revealing nothing about which items interested it.

What it teaches

BIP37 is worth understanding even in retirement, because it is a clean case study in how privacy designs fail: the cryptography worked exactly as specified, but the information flow — who sends what to whom — leaked everything that mattered. Probabilistic matching cannot save you if the adversary is the counterparty you hand your filter to. The successor design succeeds not with fancier math but with a better trust arrangement: download everything small, filter on your own machine, reveal nothing. That pattern — move the computation to the edge you control — recurs across sovereign infrastructure, from block filters to self-hosted AI. For the light-client foundation both generations build on, see headers-first sync; and remember that the strongest wallet privacy remains a wallet backed by your own full node, where no filter protocol is needed at all.

There is a present-day lesson hiding in the history: many light wallets that abandoned BIP37 now query public Electrum-style servers instead, which see your addresses in cleartext — the same leak with different plumbing, merely relocated from a random peer to a semi-trusted server operator. The categorical fix has not changed in a decade: point your wallet at a backend you run yourself, and no third party ever learns which coins are yours, because the question is never asked outside your own hardware. Nodes that do still serve legacy filtering advertise it explicitly as a service flag, so the capability is opt-in rather than ambient — a small design courtesy the original deployment lacked.