Compact Block Filters to probabilistyczne indeksy bloków dla lekkich klientów. Portfel pobiera filtr i sprawdza skrypty lokalnie, zamiast wysyłać serwerowi własny filtr adresów jak w BIP 37. BIP 157 i BIP 158 mają podczas przeglądu status Deployed, lecz nie zastępują pełnej walidacji konsensusu.
BIP 157 definiuje getcfilters/cfilter, getcfheaders/cfheaders i getcfcheckpt/cfcheckpt. BIP 158 określa filtr basic typu 0x00. Klient synchronizuje najpierw nagłówki bloków, potem nagłówki filtrów i filtry; po trafieniu pobiera blok i wyszukuje rzeczywiste transakcje. To nie Compact Blocks z BIP 152 do szybkiego przekazywania bloków. [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters for Light Clients]
Filtr zawiera scriptPubKey nowych wyjść poza skryptami zaczynającymi się od OP_RETURN oraz skrypty poprzednich wyjść wydawanych przez wejścia, z wyjątkiem wejścia coinbase. Puste elementy są pomijane, a elementy tworzą zbiór. Nie jest to indeks wszystkich txid, ciągów adresów lub danych witness; budowa wymaga także wydawanych poprzednich wyjść. [BIP 158 — Compact Block Filters for Light Clients]
Wartości SipHash-2-4 mapuje się do zakresu N × M, sortuje, a różnice koduje Golomb-Rice. Basic używa P=19 i M=784931; kluczem jest pierwszych 16 bajtów hasha bloku w little-endian. Serializacja zaczyna się od N w CompactSize. Zapytanie spoza zbioru może dać fałszywe trafienie z prawdopodobieństwem około 1/M; prawidłowy filtr nie pomija zawartego elementu. [BIP 158 — Compact Block Filters for Light Clients]
Hash filtra to double-SHA256 jego serializacji. Nagłówek to double-SHA256 tego hasha połączonego z poprzednim nagłówkiem filtra. Tworzy to sprawdzalne powiązanie, ale zobowiązanie nie znajduje się w konsensusowym nagłówku bloku. Samo hashowanie nie wykryje spójnie fałszywego łańcucha dostarczonego przez wszystkich połączonych peerów. [BIP 157 — Client Side Block Filtering]
BIP 157 zaleca kilku niezależnych peerów, chyba że istnieje bezpieczne połączenie z zaufanym peerem. Przy sprzeczności klient znajduje pierwszą różnicę i sprawdza filtr względem bloku oraz potrzebnych danych wcześniejszych wyjść. Gwarancja poprawnych filtrów zakłada co najmniej jednego uczciwego peera. Po reorganizacji filtry muszą podążać za nową gałęzią, a odpowiedni stan portfela wymaga ponownego obliczenia. [BIP 157 — Client Side Block Filtering] [BIP 158 — Compact Block Filters for Light Clients]
Lokalne sprawdzanie nie ujawnia peerowi szukanych skryptów. Późniejsze żądania pełnych bloków ujawniają jednak zainteresowanie i można je korelować z IP lub powtarzanymi zapytaniami. BIP 157 zaleca losowo wybierać źródła bloków wśród peerów wychodzących; źródło bloku nie musi serwować filtrów. To nie gwarancja anonimowości. [BIP 157 — Client Side Block Filtering]
Filtr dotyczy potwierdzonego bloku, nie bieżącego Mempool. Trafienie nie dowodzi płatności ani prawa wydawania; decydują transakcje i wymagane kontrole. Węzeł może zachować filtry po przycięciu bloków, lecz wtedy może nie dostarczyć starego pełnego bloku. Oszczędności lekkiego klienta nie zastępują modelu bezpieczeństwa Full Node. [BIP 157 — Client Side Block Filtering]
W Bitcoin Core 29.0 opcja -blockfilterindex tworzy indeks; -peerblockfilters włącza udostępnianie peerom i wymaga indeksu basic. NODE_COMPACT_FILTERS sygnalizuje usługę. RPC getblockfilter zwraca filter i header dla wybranego bloku. Sama dostępność RPC lub indeksu nie oznacza serwowania filtrów przez P2P; hasło nie zmienia konfiguracji węzła. [Bitcoin Core 29.0 — getblockfilter RPC] [Bitcoin Core 29.0 — Filter service configuration]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Neutrino, Full Node, Pruned node, Prywatność w Bitcoinie, Compact block relay. Do tego hasła prowadzą również odsyłacze z Compact Block Filters, Neutrino.