Bitcoin Core peerbloomfilters Explained: BIP37 Service Control

This guide explains Bitcoin Core peerbloomfilters in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.

What BIP37 provides

A client sends a probabilistic filter describing items of interest, and the peer returns matching transactions or merkle-block proofs. False positives obscure the exact set somewhat, but repeated filters and requests can reveal wallet structure. The full node validates the chain; the lightweight client receives a filtered view and different security guarantees.

Service-bit signalling

Supporting bloom filters is advertised through the NODE_BLOOM service bit under release-specific negotiation. Core 0.12 tied that advertisement and message handling to peerbloomfilters. Compatibility checks should inspect actual version handshakes and requests rather than assume configuration alone reached every listener.

Privacy limitations

Bloom-filter queries are not private search. An observing peer can correlate addresses, transaction graph fragments, timing and network origin across filter updates. False positives do not eliminate that risk. Wallet operators should prefer current compact-filter or full-node approaches where supported and evaluate network privacy separately.

Resource and abuse surface

Serving filterload, filteradd and merkle-block requests consumes CPU, memory and bandwidth. Malicious or poorly behaved clients can amplify work. Core added limits and later changed support policy. Public operators should measure request volume and keep the node patched rather than using a single Boolean as the whole defence.

Compatibility consequences

Turning the option off can break older SPV wallets that depend on that node, even while ordinary full-node peers work normally. Inventory clients, software versions, connection paths and fallback providers before change. A silent fallback to a third-party server can worsen privacy even if the wallet appears functional.

Mining infrastructure relevance

Pool validators generally do not need BIP37 for consensus or template construction. Exposing it on a private validation node adds service surface without direct mining benefit. If customer wallets require legacy access, isolate the public service and avoid coupling its load or privacy records to the template node.

Disablement rehearsal

Connect a controlled BIP37 client with support enabled, capture the service bit and a successful filtered request, then disable it and verify the documented rejection or disconnection. Confirm full-node block relay, RPC, ZMQ and mining templates remain healthy. Test client fallback and disclose any third-party dependency.

Conclusion

peerbloomfilters controls a legacy lightweight-client service, not Bitcoin validity. Operate it only for an identified compatibility need, with privacy disclosure, resource monitoring and a tested migration path.