Compact Block Filters jsou malé přehledy obsahu bitcoinových bloků. Peněženka si je stáhne a u sebe zjišťuje, ve kterých blocích by mohly být její platby. Teprve vybrané bloky si vyžádá celé. Šetří tak data a méně odhaluje, co hledá. Shoda ve filtru však ještě není důkazem platby a tento postup nenahrazuje úplné ověřování bitcoinových pravidel.
Anna čeká platbu v mobilní peněžence. Peněženka je aplikace nebo zařízení pro přijímání a odesílání bitcoinů. Bloky jsou balíky transakcí, ale telefon nemusí stahovat každý z nich celý. Může nejprve procházet jejich malé filtry, podobně jako rejstřík knihy před otevřením příslušné stránky. Každý uživatel dostává pro stejný blok a typ filtru stejný přehled; výběr podle Anniny peněženky probíhá až v telefonu. Technické dokumenty BIP 157 a BIP 158 si práci rozdělují: první určuje získávání a kontrolu filtrů, druhý jejich obsah a sestavení. Peněženka nejprve ověří hlavičky bloků, tedy jejich základní údaje a návaznost v řetězci, potom načte kontrolní údaje filtrů a samotné filtry. Při shodě stáhne celý blok a hledá skutečnou transakci. Podobně znějící Compact Blocks z BIP 152 řeší jiný problém: rychlé předávání nových bloků mezi uzly. Uzel je program, který ověřuje transakce a bloky a komunikuje s dalšími účastníky sítě. [1] [2] [5] [6]
Bitcoinová transakce vytváří výstupy: částky s podmínkami pro jejich pozdější utracení. Zápis těchto podmínek se jmenuje scriptPubKey. Vstup nové transakce zase odkazuje na starší výstup, který utrácí. Základní filtr basic, označený 0x00, proto zahrnuje jak skripty nových výstupů, tak skripty utrácených předchozích výstupů. Anna díky tomu může hledat přijetí i utracení prostředků. Z nových výstupů se vynechávají skripty začínající OP_RETURN, instrukcí označující neutratitelný výstup. Vynechán je také zvláštní vstup coinbase transakce, která přiděluje odměnu těžaři. Její vstup žádný předchozí výstup neutrácí. Prázdné položky se nepřidávají a opakovaná položka se počítá jen jednou. Nejde o seznam všech txid neboli identifikátorů transakcí, textových adres ani witness dat, například podpisů. K sestavení správného filtru nestačí samotný nový blok: potřebné jsou i údaje o předchozích výstupech, které jeho transakce utrácejí. [2]
Server by mohl Anně poslat přehled, ze kterého její platbu úmyslně vynechal. Peněženka proto nekontroluje jen obsah filtru, ale i jeho návaznost. Hash je krátký digitální otisk dat. Z uloženého filtru se vypočte double-SHA256, tedy SHA-256 použitý dvakrát. Tento otisk se spojí s předchozí hlavičkou filtru a stejným postupem vznikne další hlavička. Změna staršího filtru se tím projeví i v navazujících kontrolních údajích. Hlavička bloku chráněná těžbou však neobsahuje otisk této pomocné řady filtrů. Pokud všechny připojené servery předloží stejnou falešnou řadu, její otisky mohou navazovat bez chyby. Matematická návaznost sama nedokazuje, že přehled odpovídá skutečnému bloku. [1]
BIP 157 proto doporučuje spojení s více nezávislými uzly, kterým se při takové komunikaci říká peers. Alternativou je bezpečné spojení s důvěryhodným uzlem, například vlastním. Dostane-li peněženka rozdílné řady filtrů, vyhledá první místo rozporu. Správný filtr může přepočítat z daného bloku a potřebných předchozích výstupů. Záruka rozpoznání správných filtrů předpokládá alespoň jednoho poctivého peera; několik spojení se stejným útočníkem tuto podmínku nesplní. Změnit se může i samotný řetězec: při reorganizaci uzly nahradí část jeho konce jinou větví s větším součtem prokázané práce. Peněženka musí přejít na filtry této větve a znovu vyhodnotit dotčené platby. Ani jednou nalezené potvrzení tedy není navždy nezávislé na tom, který řetězec síť přijímá. [1] [2]
Ve starším postupu BIP 37 posílala peněženka serveru vlastní filtr toho, co chce sledovat. U Compact Block Filters si naopak stáhne obecná data a osobní výběr provede u sebe. To omezuje únik informací o sledovaných skriptech. Poskytovatel ale stále vidí, které celé bloky si Anna následně vyžádá, a může požadavky spojovat s její IP adresou, tedy síťovou adresou připojení. Z opakovaných návštěv může odhadovat další souvislosti. BIP 157 proto doporučuje zdroje celých bloků náhodně vybírat mezi uzly, ke kterým se peněženka sama připojila. Blok může dodat i jiný uzel než filtr. Soukromí se tím zlepšuje, nevzniká však záruka anonymity. [1]
Filtry popisují bloky již zařazené do řetězce. Nejsou přehledem aktuálního Mempool, tedy nepotvrzených transakcí, které má konkrétní uzel připravené k dalšímu šíření či těžbě. Shoda také nedokazuje, že Anna vlastní klíč potřebný k utracení nalezených prostředků. Soukromý klíč je tajný číselný údaj, kterým peněženka vytváří digitální podpis pro schválení útraty. Peněženka musí zkontrolovat skutečnou transakci a její zařazení do bloku. Lehký klient přesto neověřuje všechny transakce všech bloků podle všech pravidel jako Full Node, plně ověřující uzel. To je skutečný bezpečnostní kompromis za úsporu dat. Další rozdíl je dostupnost: Pruned Node může po ověření staré bloky smazat a ponechat si jejich filtry. Anna se pak dostane k přehledu, ale celý starý blok musí získat jinde. Samotné prořezávání neznamená, že uzel přestal plně ověřovat pravidla. [1] [5]
Malá velikost má svou cenu: filtr může odpovědět „možná ano“, i když hledaná položka v bloku není. Této plané shodě se říká false positive. Anna pak stáhne blok zbytečně, ale její peněženka v něm domnělou platbu nenajde a nemá ji započítat. Správný filtr naopak nevynechá položku, kterou podle svých pravidel skutečně zahrnuje; tato vlastnost neomlouvá falešná data od nepoctivého serveru. Technicky se položky pomocí SipHash-2-4 převádějí na čísla v rozsahu o velikosti N × M, kde N je počet položek. Čísla se seřadí a uloží se úsporně jejich rozdíly pomocí Golomb-Rice kódování. Parametr P=19 řídí kódování, M=784931 ovlivňuje četnost náhodných shod; u jedné hledané položky mimo množinu je pravděpodobnost přibližně 1/M. Bajt je běžná jednotka množství dat. Klíč pro SipHash tvoří prvních 16 bajtů hashe bloku v pořadí little-endian, tedy od méně významných bajtů. Nejde o tajný klíč peněženky. SipHash zde data nezašifruje, pouze je převádí na čísla pro filtr. Uložený filtr začíná počtem N zapsaným ve formátu CompactSize pro celá nezáporná čísla. [2]
Oba dokumenty mají při revizi k datu 2026-10-17 stav Deployed, tedy nasazený protokol; to neznamená podporu v každé peněžence. Následující příklad nastavení se vztahuje konkrétně k Bitcoin Core 29.0. Volba -blockfilterindex vytvoří místní index filtrů. Teprve -peerblockfilters zapíná jejich poskytování jiným uzlům a vyžaduje index basic; podporu oznamuje příznak NODE_COMPACT_FILTERS. Programové rozhraní RPC dovoluje příkazem getblockfilter získat pole filter s obsahem a header s hlavičkou pro vybraný blok. Funkční RPC tedy samo neprokazuje dostupnost filtrů ostatním uzlům v síti. Pro čtenáře specifikace: dvojice zpráv getcfilters/cfilter přenáší filtry, getcfheaders/cfheaders údaje pro návaznost a getcfcheckpt/cfcheckpt kontrolní body této pomocné řady. Jsou to technické názvy síťové komunikace, nikoli příkazy, které musí zadávat uživatel mobilní peněženky. [3] [4]
Pro nejúplnější obraz čtěte toto heslo společně s Neutrino, Full Node, Pruned Node, Soukromí v Bitcoinu, Compact Blocks, Mempool. Opačným směrem na něj odkazují také Compact Block Filters, Neutrino.