BIP 37 Bloom filters explained: review filtered-block relay, false positives, privacy leakage, resource risk and why modern clients moved away.
This guide explains BIP 37 Bloom filters in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
BIP 37 Bloom filters: Remote filters require a full node to scan transaction data and maintain per-peer state. Attackers can choose costly filters or repeatedly update them.
A node operator is checking BIP 37 Bloom filters. A client must not assume that a random modern Bitcoin peer offers BIP 37. False positives are expected.
A client that does not download every block still needs evidence that relevant transactions were confirmed. Asking a peer for exact addresses or outpoints reveals the wallet immediately. BIP 37 lets the client upload a probabilistic filter and receive matching transactions plus partial merkle proofs, reducing data compared with full blocks while attempting to add cover traffic.
A Bloom filter is a bit field updated by several hash functions. It can say that an element is definitely absent or possibly present. False positives are expected; false negatives should not occur when construction and updates are correct. Filter size, number of hash functions and tweak influence the false-positive rate and resource cost.
A client sends filterload to install its filter, can add elements with filteradd and clear state with filterclear. It requests filtered blocks and receives merkleblock messages containing the block header, partial merkle tree and matched transaction identifiers, followed by relevant transactions. The client must validate proof of work, header chain and merkle reconstruction.
Peers can combine filter contents, connection timing, requested history and later filter updates to infer wallet addresses and transaction graph. Low false-positive settings make matching more precise, while high rates increase bandwidth without guaranteeing anonymity. Connecting through several observers can spread rather than remove leakage when results are correlated.
Remote filters require a full node to scan transaction data and maintain per-peer state. Attackers can choose costly filters or repeatedly update them. Implementations added service flags, limits and eventually disabled serving by default in common configurations. A client must not assume that a random modern Bitcoin peer offers BIP 37.
BIP 157 and BIP 158 let servers provide deterministic compact filters for blocks. The client downloads filters and performs matching locally, so it does not upload its wallet interest set to each peer. It may then fetch relevant full blocks. This changes bandwidth and trust trade-offs but substantially improves query privacy.
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
BIP 37 Bloom filters: Remote filters require a full node to scan transaction data and maintain per-peer state.
A client that does not download every block still needs evidence that relevant transactions were confirmed.
A Bloom filter is a bit field updated by several hash functions.
A client sends filterload to install its filter, can add elements with filteradd and clear state with filterclear.
BIP 37 was an important lightweight-wallet milestone, but its server-side interest filters leak more information and consume more peer resources than the original intuition suggested. New systems should favour client-side compact filters or their own validating node, while legacy support is carefully bounded and tested.
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
BIP 331 package relay explained for mining nodes: understand ancestor packages, orphan handling, fee bumps, combined hashes and draft protocol limits.
BIP 338 guide covering its Closed status, disabletx proposal, block-relay-only connections, version-message limits, negotiation, compatibility and successor context.
BIP 339 wtxid relay explained: see why witness-aware transaction identifiers improve Bitcoin peer announcements, requests and rejection handling.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.