When a light Bitcoin wallet asks the network for its own activity, what it sends across the wire is essentially a description of its own interests. Compact block filters invert that arrangement: instead of the wallet uploading a filter that tells peers which transactions it cares about, the wallet downloads a filter that describes every transaction in a block and matches locally. That inversion moves the privacy question away from the outgoing request and into the matching step, and it draws a sharp line around what the filters can and cannot promise.
The older method, specified in BIP37, has a client set a Bloom filter on a connection and lets the remote peer use it to select matching transaction data. BIP157 changes the direction: full nodes generate deterministic filters from block contents, and a client downloads a filter and compares it against the scripts it watches. Because the filter is a function of the block rather than of any single wallet, the request no longer carries a wallet-specific matching set. That is a genuine privacy boundary, but it applies only to the matching step.
The basic filter defined in BIP158 is also narrower than a casual reading suggests. It indexes the previous output script for each input except coinbase inputs, and the output scriptPubKeys except OP_RETURN outputs, with nil entries excluded. Those are the scripts tied to spending and receiving, not an index of every field in a transaction, and because the filter is built from block contents it is not a mempool feed. Anyone relying on it should confirm which scripts their wallet actually watches and how those map to the filter’s coverage.
A match is a reason to look, not proof of a payment. BIP158’s construction is probabilistic, so a queried value can match even when the underlying set does not contain it, while a correctly built filter matches everything it does contain. When a match appears, the client downloads the block and inspects its transactions, and a false-positive match resolves to nothing. Treating a match as evidence of an amount, a recipient, or a spendable balance overreads what the data structure provides.
BIP157 also chains filter headers together and recommends checking downloaded filters against them, so a peer serving a bad filter can be identified and dropped. These commitments are peer-to-peer, not the consensus commitments embedded in Bitcoin block headers, and the design rests on there being at least one honest peer plus the client’s own checks. A client surrounded entirely by dishonest peers cannot manufacture correctness out of cross-peer agreement.
The remaining steps stay separate. BIP157 suggests fetching full blocks from randomly selected outbound peers to blunt transaction-intersection analysis, but that is a mitigation for which blocks a client requests, not a guarantee of anonymity or IP-address protection. And the light-client model verifies proof-of-work headers and header-chain inclusion rather than the validity of every block, so it is not full-node validation. A wallet can get the filter step right and still leak through retrieval or the wrong chain checks.
For anyone choosing a light client, the useful questions follow the same order: which filter type and scripts are covered, whether downloaded filters are checked against their headers, how the client behaves when peers disagree, how full blocks are fetched and by whom, and which chain checks actually run. A favorable answer about local matching cannot settle the retrieval question, and correct filter handling cannot establish full validation.
Source: BTCUSA.