Bloom Filter (BIP37)

BIP37 introduced 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: 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 the rest with 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.

Why it fell out of favor

The privacy model is 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 correlate a wallet's addresses and link them to the client's IP. Because of this, and the load filtering placed on serving nodes, Bitcoin Core has disabled serving BIP37 filters by default since version 0.19. The privacy-preserving successor is the client-side-matching model of compact block filters.

For the modern alternative that does not reveal addresses, see Compact Block Filters (BIP158). For the broader light-client foundation, see Headers-First Sync.