A Bitcoin wallet needs a way to discover incoming payments and notice when its coins have been spent. One approach, compact block filtering, lets the wallet download small summaries of blocks and check them locally. It requests a full block when a summary suggests relevant activity. The design reduces the information a wallet needs to disclose while looking for its own transactions. BIP 157 describes the protocol.
That is useful for understanding a mobile wallet's connection settings. Holding the keys yourself answers who can authorize spending. A separate question is how the application learns what happened on the blockchain, and what that process reveals.
Move the search onto the wallet
An earlier light-client design, BIP 37, has the wallet send a Bloom filter to a peer. The peer tests transaction data against that filter and sends matching information back. The filter includes deliberate uncertainty, allowing unrelated transactions to match too. Its specification acknowledges a tradeoff: a very precise filter saves bandwidth but can help the peer correlate transactions with the client's network address. BIP 37 connection filtering
Compact block filters reverse the direction of that search. The server supplies the same deterministic block summary to clients; each wallet checks its own interests privately on its device. A server therefore does not need an individualized list of addresses to decide which filters to return. The wallet can obtain a matching block from a different peer. Client-side filtering design
A match is a reason to investigate
BIP 158 defines the contents and compressed format of the basic filter. It covers the output scripts created by transactions, except outputs beginning with OP_RETURN, and the previous output scripts spent by non-coinbase inputs. Those scripts describe spending conditions; the filter is not simply a directory of familiar-looking address strings. BIP 158 filter contents
The compression permits false positives. A correctly constructed filter will match included items, but can also match an unrelated item. Consequently, the wallet must inspect the relevant block before deciding that a payment exists. In a hypothetical scan, two matching filters might lead to two block downloads while only one contains a wallet transaction. That extra download is expected behavior, not evidence of an extra payment. BIP 158 matching rules
Bitcoin Core's getblockfilter interface illustrates the limited object involved: it returns encoded filter data and a filter header for a specified block. It does not return a wallet balance or identify an owner. Bitcoin Core RPC documentation
Peer checks have a specific purpose
BIP 157 links filters through filter headers and lets clients compare responses from multiple peers. When responses disagree, clients can investigate the disputed block. The protocol's assurance of identifying correct filters depends on reaching at least one honest peer. Filter commitments are not embedded in Bitcoin's consensus block headers by this design. BIP 157 verification and rationale
Even correct filters do not turn a light client into a fully validating node. The Bitcoin developer guide distinguishes checking that a transaction appears in a block from independently validating all of the chain's transactions. A wallet's discovery method and its validation model should therefore be examined separately. Network isolation also matters: multiple connections are less useful when an attacker controls every peer the client reaches. Bitcoin operating modes
Check what happens before confirmation
A block filter summarizes a block that already exists. It is not a feed of every unconfirmed transaction. Neutrino, a light-client implementation designed with mobile Lightning applications in mind, documents that its receive and spend notifications occur after confirmation rather than when transactions first enter the mempool. This is a documented implementation behavior, not a claim about every wallet using filters. Neutrino documentation
If an app displays incoming payments sooner, ask where that additional information comes from. The answer may affect both availability and privacy. Also ask how the wallet resumes scanning after time offline and what starting point it uses during restoration. Neutrino's rescan interface, for example, accepts a starting and ending block. These details help explain why opening a restored wallet and completing its history scan can be separate events.
Read the whole privacy design
Compact filters address transaction discovery. They do not conceal Bitcoin's public ledger or remove information someone publishes beside an address. Bitcoin.org's privacy guidance warns that public transaction records can be linked with identifying details. Bitcoin privacy guidance
When evaluating a wallet, look for a concrete description of its filter sources, block-download behavior, transaction broadcasting and optional server services. Our recommendation is to ask which data leaves the device at each stage, rather than relying on a single privacy label. Compact filtering can improve one important step while leaving other steps worth understanding.