Compact Block Filter

Overview

Compact block filters summarize selected elements from a block in a space-efficient structure. In Bitcoin, BIP 157 and BIP 158 define client-server protocols and Golomb-coded sets that let lightweight clients test locally whether a block may match wallet scripts. Filters can produce false positives but should not produce false negatives when built correctly. Clients download matching blocks and perform normal verification, avoiding direct address queries that would reveal wallet interests to a server.

Wallets should validate filter-header chains, obtain filters from suitable peers, and scan every relevant height. A match is only a prompt to inspect the block, not proof of payment. High-assurance systems should use full nodes or audited indexes for complete deposit coverage.

Verification of Compact Block Filter should begin with a canonical block identifier rather than a height alone. Competing blocks can temporarily occupy the same height, and a reorganization can replace data that was previously observed, so applications should retain hashes and update dependent records when canonicality changes. Teams should document which component supplies the data and how missing, malformed, or version-unknown records are handled. Operational use of Compact Block Filter depends on node mode and data retention. Pruned, archive, light, and indexing services may expose different historical fields or proofs.

Test fixtures for Compact Block Filter should cover normal blocks, boundary sizes, protocol upgrades, and invalid encodings. Parsing should be version-aware and fail closed when an unknown format affects validation, accounting, or settlement decisions. Operational takeaway: Compact block filters improve private light-wallet discovery, while matched blocks still require full transaction and chain validation.