Compact Block Filters sont de petits index probabilistes construits de manière déterministe pour chaque bloc. BIP 158 définit contenu et encodage, BIP 157 transmission et contrôle de continuité ; le client compare ses scripts localement.
Le portefeuille synchronise les en-têtes de blocs et de filtres, télécharge les filtres et teste ses scripts localement. Après correspondance, il obtient le bloc entier et cherche la transaction réelle. Le solde ne doit pas augmenter sur cette seule base : le filtre ne fournit ni montant, ni preuve de propriété, ni historique complet. [BIP 157 — Client Side Block Filtering]
BIP 158 basic inclut les scriptPubKey des nouvelles sorties, sauf celles commençant par OP_RETURN, et les scripts des anciennes sorties dépensées par les entrées hors coinbase. Les éléments vides sont omis. Il faut convertir l’adresse en script correct ; ce n’est pas un index universel de txid, de données witness ou de notes quelconques. [BIP 158 — Compact Block Filters for Light Clients] [Bitcoin Core — BasicFilterElements]
Golomb-Rice encode les différences entre valeurs hachées triées ; basic utilise P=19 et M=784931. Une requête absente peut correspondre avec une probabilité proche de 1/M. Davantage de scripts surveillés offrent plus d’occasions de collision, pas un taux d’erreur fixe du portefeuille. Un filtre correct n’omet aucun élément inclus. [BIP 158 — Compact Block Filters for Light Clients]
L’en-tête relie le hash du filtre actuel à l’en-tête précédent. Vérifier la continuité détecte une divergence avec une chaîne déjà acceptée, mais cet engagement ne figure pas dans l’en-tête du bloc Bitcoin. Un attaquant peut fournir de faux filtres cohérents entre eux ; un hash correct ne garantit pas seul un contenu véridique. [BIP 157 — Client Side Block Filtering]
BIP 157 détecte les faux filtres en comparant les pairs, avec au moins un participant honnête. Reconstruire basic peut aussi nécessiter les scripts des anciennes sorties dépensées. Une réorganisation exige de suivre les filtres de la nouvelle branche et de recalculer l’état du portefeuille ; une même hauteur ne désigne pas forcément le même bloc. [BIP 157 — Client Side Block Filtering] [Bitcoin Core — BasicFilterElements]
Contrairement à BIP 37, le client n’envoie pas son filtre d’adresses au serveur. Un pair peut encore observer l’adresse IP, les horaires et les blocs demandés. Répartir les téléchargements entre pairs limite la concentration des informations, pas toutes les corrélations ; les correspondances accidentelles ne rendent pas seules la communication anonyme. [BIP 157 — Client Side Block Filtering]
Bitcoin Core RPC getblockfilter renvoie filtre et en-tête pour un hash de bloc lorsque l’index correspondant est activé. Cela ne prouve ni un service P2P public ni la capacité du pair à fournir tous les anciens blocs. Le client doit disposer d’une source de blocs fonctionnelle ; ces filtres n’annoncent pas les transactions non confirmées du Mempool. [BIP 157 — Client Side Block Filtering] [Bitcoin Core 30.0 — getblockfilter]
Compact Blocks selon BIP 152 accélèrent la transmission des nouveaux blocs grâce aux identifiants courts et au Mempool local. Compact Block Filters sélectionnent les blocs pertinents pour le client. Ni correspondance locale ni vérification d’inclusion ne remplacent la validation complète et indépendante du consensus de tous les blocs. [BIP 157 — Client Side Block Filtering] [BIP 152 — Compact Block Relay]
Pour une vision complète, lisez aussi Compact Block Filters, Neutrino, Full Node, Confidentialité de Bitcoin, Compact block relay. Cette entrée est également citée par Neutrino.