BIP 157 – Client-Side Block Filtering

Bitcoin was built to be openly accessible, yet full participation traditionally required running a resource-intensive node. This created a practical barrier for millions of users whose devices could not independently verify transactions or maintain a synchronized copy of the blockchain. BIP 157 offers a redesign of how light clients interact with Bitcoin’s data, shifting crucial discovery work to established full nodes without reducing user control.

By introducing compact block filters, the proposal enables software wallets to detect relevant transactions while maintaining autonomy and privacy. Devices with limited connectivity or storage—such as mobile phones, hardware wallets, or embedded modules—can stay meaningfully connected without streaming large data sets.

Purpose of BIP 157

BIP 157 modernizes Simplified Payment Verification by replacing Bloom-filter-based scanning with a more private and robust mechanism. Instead of uploading address patterns, clients download compact filters published by full nodes and perform transaction discovery locally.

This inversion of responsibility strengthens user privacy. A mobile wallet connected to public Wi-Fi does not expose which addresses belong to the user. Only the device itself evaluates whether a transaction is relevant.

All light clients receive identical filter data. Observers cannot distinguish wallets by request patterns, and address ownership remains concealed.

Key Technical Differences

The fundamental change introduced by BIP 157 is that full nodes generate deterministic filters once per block. These filters summarize block contents, allowing wallets to test relevance without inspecting transactions directly.

The protocol also supports multi-peer verification. A wallet may compare filter headers from multiple nodes and discard peers whose data deviates, reducing reliance on any single source.

Aspect	Before (BIP 37)	After (BIP 157)
Who generates filters	Client-generated Bloom filters	Full nodes generate compact filters
Privacy exposure	Wallet interests leaked to peers	Interests remain private
Network behavior	Queries differ per wallet	Uniform data for all clients
Full node load	Unpredictable and heavy	Deterministic and cacheable
Client bandwidth	Often downloads irrelevant blocks	Downloads blocks only when relevant
Trust model	Trusts nodes for accuracy	Cross-checks peers via headers
Attack surface	Susceptible to filtering attacks	Tampering detectable

Protocol Messages and Validation

BIP 157 introduces new peer-to-peer messages for compact filters, filter headers, and range requests. A light client first synchronizes the filter header chain, then retrieves filters for new blocks.

Each filter header commits to the previous one, forming a verifiable chain. Incorrect or manipulated filters result in mismatches that are immediately detectable, allowing clients to drop dishonest peers.