Compact Block Filters are small, deterministically constructed probabilistic indexes of individual blocks. BIP 158 defines contents and encoding, while BIP 157 covers delivery and continuity checks; the client compares watched scripts locally.
The wallet syncs block and filter headers, downloads filters and tests its scripts locally. On a match it obtains the whole block and looks for the actual transaction. A match alone must not increase the balance: the filter returns neither an amount, proof of ownership nor complete transaction history. [BIP 157 — Client Side Block Filtering]
BIP 158 basic includes new outputs’ scriptPubKey except those starting with OP_RETURN, plus previous output scripts spent by non-coinbase inputs. Empty items are omitted. An address string must become the correct script; the filter is not a universal index of txid, witness data or arbitrary notes. [BIP 158 — Compact Block Filters for Light Clients] [Bitcoin Core — BasicFilterElements]
Golomb-Rice coding stores differences between sorted hashed values; basic uses P=19 and M=784931. One nonmember query may match with probability approximately 1/M. More watched scripts create more collision opportunities, not a fixed wallet-wide error rate. A correctly constructed filter does not omit an included element. [BIP 158 — Compact Block Filters for Light Clients]
A filter header links the current filter hash with the previous header. Checking continuity detects disagreement with an already accepted chain, but this commitment is not in the Bitcoin block header. An attacker can supply internally consistent false filters; a correctly calculated hash alone does not guarantee true contents. [BIP 157 — Client Side Block Filtering]
BIP 157 detects false filters by comparing peers with at least one honest participant. Reconstructing basic may also need the scripts of spent previous outputs. A reorganisation requires following filters on the new branch and recalculating wallet state; the same old height does not identify the same block. [BIP 157 — Client Side Block Filtering] [Bitcoin Core — BasicFilterElements]
Unlike BIP 37, the client sends no personal address filter to a server. A peer may still observe the IP address, timing and requested blocks. Fetching blocks from different peers limits concentration of this information, not every correlation; accidental matches alone do not make communication anonymous. [BIP 157 — Client Side Block Filtering]
Bitcoin Core RPC getblockfilter returns a filter and its header for a block hash when the corresponding index is enabled. This alone proves neither a public P2P service nor that the peer can serve every historical block. Clients need a working block source; filters of completed blocks do not announce unconfirmed Mempool transactions. [BIP 157 — Client Side Block Filtering] [Bitcoin Core 30.0 — getblockfilter]
Compact Blocks under BIP 152 accelerate new-block transmission with short transaction identifiers and the local Mempool. Compact Block Filters select relevant blocks for a client. Neither local matching nor checking transaction inclusion replaces independent full consensus validation of all blocks. [BIP 157 — Client Side Block Filtering] [BIP 152 — Compact Block Relay]
For the clearest picture, read this entry together with Compact Block Filters, Neutrino, Full Node, Bitcoin Privacy, Compact block relay. The reverse links also lead from Neutrino.