Block Filter

Overview

A block filter summarizes selected elements from a block in a compact structure, commonly using a probabilistic encoding. A lightweight wallet tests the filter for scripts or patterns it cares about and downloads the full block only when the result may match. Filters can produce false positives but should not produce false negatives when constructed correctly for the defined element set. Clients still need authenticated filter headers or another commitment chain to detect peers serving inconsistent filters, and a match does not prove a payment exists.

Wallets should retrieve and validate the corresponding block before updating balances. Privacy depends on the download strategy because querying a peer directly for specific matches can reveal addresses of interest. Payment systems requiring complete coverage should rely on full validation or audited indexing rather than filters alone. Test fixtures for 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. Field names can appear similar across networks while using different byte order, commitment schemes, size limits, activation heights, or relationships to the block header and body. Block Filter must be interpreted under the exact chain rules and software version that define its encoding and validation. Verification of 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.