Bloom filter

The design traded bandwidth for what its authors hoped was privacy, and the privacy never arrived. Bitcoin Core stopped serving these filters by default in version 0.19.0, released in November 2019, after years of research showed how much they leak. A wallet still relying on one is handing a stranger's machine a workable list of the coins you own.

How it works

Status: BIP37 bloom filtering was switched off by default in Bitcoin Core 0.19.0 in November 2019, and the BIP157 and BIP158 compact block filters took over the light-wallet job.

A bloom filter is an array of bits plus a handful of hash functions. To insert an item you hash it several ways, take each result modulo the array length, and set those bits to one. To test an item you hash it the same ways and look. If any of those bits is zero the item was definitely never inserted; if all of them are one the item was probably inserted, or other insertions happened to set the same bits. False negatives cannot occur. False positives can, and their rate is the tuning knob.

BIP37 fixed the arithmetic. A filter is capped at 36,000 bytes and 50 hash functions, and the hashing is version 3 of the 32-bit Murmur function seeded with the hash number multiplied by 0xFBA4C795 plus a client-chosen tweak. Three messages drive it: filterload installs a filter on the connection, filteradd extends it, filterclear removes it. Once a filter is set, the peer answers a block request with a merkleblock carrying the 80-byte header, the transactions that matched, and the merkle branches proving they belong to that block. BIP111 later added a NODE_BLOOM service bit so a node could advertise whether it would play along at all.

The privacy story rested entirely on that false positive rate. Widen the filter, catch strangers' transactions alongside your own, and an observer supposedly cannot tell which are which. It does not hold. Academic work published in 2014 showed that a filter carrying a realistic number of addresses gives up most of them, and that two filters loaded by the same wallet can be intersected to strip the camouflage away. Reconnecting to a fresh peer with a new filter makes the problem worse, not better.

The other failure was cheaper to explain. Serving a filter means scanning blocks off disk on a stranger's instruction, so any peer could make a node with a spinning disk do an enormous amount of unpaid work. That denial of service argument, not the privacy research, is what the 0.19.0 release notes lead with.

Where you see it

Bloom filters survive mostly in software written before 2019 and in configuration files that work around their absence.

Android wallets built on the bitcoinj library used BIP37 as their only chain backend, and some are still installed. Bisq needed it too, which is why its documentation used to instruct people to add peerbloomfilters=1 to their own node's configuration. That line is the tell: when a piece of software asks you to re-enable bloom filtering on a node you run, it is asking for a technique the reference client turned off for good reasons.

The modern replacement runs the other way round. Under BIP157 and BIP158 the node builds one filter per block and publishes it to everybody, and the wallet matches on its own hardware, so nothing about your addresses leaves the device.

Bloom filter vs SPV

A bloom filter was a delivery mechanism; simplified payment verification is a trust model, and blurring the two makes people assume the model died with the mechanism. SPV means checking that a transaction sits under the merkle root of a header in the most-work chain, without validating the rest of that chain's contents. That reasoning is unchanged. What changed is how a light wallet finds the transactions worth checking: it used to broadcast a lossy sketch of its own addresses and hope, and now it downloads a filter per block and tests it at home.