Compact Block Filters are probabilistic block indexes for light clients. A wallet downloads a filter and tests its scripts locally instead of sending a personal address filter to a server as in BIP 37. BIP 157 and BIP 158 are Deployed at review, but do not replace full consensus validation.
BIP 157 defines getcfilters/cfilter, getcfheaders/cfheaders and getcfcheckpt/cfcheckpt messages. BIP 158 specifies the basic filter type 0x00. Clients first synchronize block headers, then filter headers and filters; on a match they fetch the block and locate actual transactions. This is distinct from BIP 152 Compact Blocks for fast block relay. [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters for Light Clients]
The filter contains new output scriptPubKey values except scripts beginning with OP_RETURN, plus scripts of previous outputs spent by inputs, excluding the coinbase input. Empty items are omitted and items form a set. It is not an index of all txids, address strings or witness data; construction also needs the previous outputs being spent. [BIP 158 — Compact Block Filters for Light Clients]
SipHash-2-4 values are mapped into N × M, sorted and their differences encoded with Golomb-Rice. Basic uses P=19 and M=784931; the key is the first 16 bytes of the block hash in little-endian form. Serialization begins with N in CompactSize. A nonmember query may match falsely with probability approximately 1/M; a correct filter does not miss an included item. [BIP 158 — Compact Block Filters for Light Clients]
The filter hash is double-SHA256 of its serialization. Its header is double-SHA256 of that hash concatenated with the previous filter header. This creates verifiable linkage, but the commitment is not in the consensus block header. Hashing alone therefore cannot expose a consistently false chain supplied by all connected peers. [BIP 157 — Client Side Block Filtering]
BIP 157 recommends several independent peers unless a trusted peer connection is secured. On disagreement, the client finds the first difference and checks the filter against the block and necessary previous-output data. Correct-filter guarantees assume at least one honest peer. After a reorganization, filters must follow the new branch and relevant wallet state must be recomputed. [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters for Light Clients]
Local matching does not reveal the watched scripts to a peer. Later full-block requests still reveal interest and can be correlated with IP addresses or repeated queries. BIP 157 recommends randomly selecting block sources among outbound peers; a block source need not serve filters. This does not guarantee anonymity. [BIP 157 — Client Side Block Filtering]
A filter concerns a confirmed block, not the current Mempool. A match proves neither payment nor spending authority; transactions and required validation determine these. A node may retain filters after pruning blocks but then may not supply an old full block. Light-client savings do not replace the Full Node security model. [BIP 157 — Client Side Block Filtering]
In Bitcoin Core 29.0, -blockfilterindex builds the index; -peerblockfilters enables serving peers and requires the basic index. NODE_COMPACT_FILTERS signals this service. The getblockfilter RPC returns filter and header fields for a chosen block. An available RPC or index alone does not mean P2P filter serving is enabled; this entry does not change node configuration. [Bitcoin Core 29.0 — getblockfilter RPC] [Bitcoin Core 29.0 — Filter service configuration]
For the clearest picture, read this entry together with Neutrino, Full Node, Pruned node, Bitcoin Privacy, Compact block relay. The reverse links also lead from Compact Block Filters, Neutrino.