Compact Block Filters jsou malé datové filtry vytvářené pro jednotlivé bloky. Blok je skupina transakcí přidaná do společné historie sítě. Tyto filtry pomáhají lehké peněžence rozhodnout, který blok by mohl obsahovat její transakce a stojí za stažení. Fungují jako úsporný orientační rejstřík s možností falešné shody. Hledání probíhá v peněžence, takže serveru nemusí poslat seznam toho, co sleduje.
Anna po delší době otevře peněženku v telefonu. Aplikace potřebuje zjistit, zda od posledního připojení někdo poslal peníze jí nebo zda se některé její prostředky utratily. Místo všech transakcí stáhne malé filtry a porovná je s podmínkami výstupů, které sleduje. Výstup je část transakce určující částku a pravidla jejího dalšího utracení. Při shodě si aplikace vyžádá celý blok a hledá skutečnou transakci. Zůstatek nemá zvýšit jen podle filtru. Ten neobsahuje hotový výpis účtu ani důkaz vlastnictví. Před hledáním si klient synchronizuje hlavičky bloků, tedy jejich stručné identifikační údaje, a navazující hlavičky filtrů. [1]
U staršího přístupu BIP 37 posílal klient protistraně filtr sestavený z údajů, které chtěl sledovat. Tady je směr opačný: server poskytne filtr bloku a Anna hledá lokálně. Pro stejný blok a typ filtru dostávají klienti stejný obsah. Nemusí tedy každému serveru přímo sdělit své hledané skripty. Neznamená to anonymitu: protistrana může vidět IP adresu, čas připojení i to, které celé bloky si peněženka následně vyžádá. Rozdělení stahování mezi různé protistrany omezuje množství informací u jedné z nich, ale všechny možnosti jejich spojování neodstraní. [1]
Compact Block Filters vybírají bloky, které stojí za kontrolu. Compact Blocks podle BIP 152 řeší jiný problém: šetří přenos při posílání bloku pomocí krátkých identifikátorů transakcí, které příjemce často už zná. Bere je ze svého Mempool, místní zásoby nepotvrzených transakcí, a chybějící si vyžádá. Ani jeden nástroj sám nerozhoduje o platnosti všech pravidel Bitcoinu. Full Node, tedy plný uzel, samostatně ověřuje bloky a transakce podle pravidel sítě. Lehká peněženka, která kontroluje jen hlavičky a zařazení své transakce, provádí užší kontrolu. Úspora dat a úplné ověření jsou rozdílné vlastnosti. [1] [5]
Pravidla formátu popisuje BIP 158. Základní filtr basic zahrnuje scriptPubKey, tedy skript s podmínkami utracení, u nových výstupů kromě těch začínajících OP_RETURN. Zahrnuje také skripty dřívějších výstupů, které se v bloku utrácejí. Při zpracování vstupů je výjimkou coinbase, první transakce bloku rozdělující odměnu těžaři, která běžné předchozí výstupy neutrácí. Její nové výstupy se posuzují podle stejných pravidel jako ostatní nové výstupy. Prázdné položky se vynechávají. Peněženka musí adresu převést na správný skript; nestačí hledat její vytištěný text. Filtr není obecný vyhledávač txid, tedy identifikátorů transakcí, ani witness dat, mezi něž patří podpisy, či libovolných poznámek. [2] [3]
Po stažení bloku může Anna zjistit, že se jí v něm nic netýká. Taková falešná shoda je běžnou cenou za malý filtr, nikoli sama důkazem chyby. Technicky se z položek vypočítají číselné otisky, seřadí se a rozdíly se úsporně uloží pomocí Golomb-Rice kódování. Pro basic platí P=19 a M=784931. Jeden dotaz na nepřítomnou položku má pravděpodobnost shody přibližně 1/M; více sledovaných položek přináší více příležitostí k ní. Nejde o pevnou chybovost celé peněženky. Správně sestavený filtr zahrnutou položku nevynechá. Zápornému výsledku však lze věřit jen při správném filtru, podporovaném druhu dat a správném dotazu. [2]
BIP 157 určuje přenos filtrů a jejich navazující hlavičky. Každá hlavička spojuje hash, tedy kryptografický otisk aktuálního filtru, s předchozí hlavičkou. Změna filtru tak poruší očekávanou návaznost. Tento řetězec však není součástí hlavičky bitcoinového bloku a těžba jeho obsah přímo nezavazuje. Nepoctivá protistrana může připravit vlastní falešné filtry i správně spočítané navazující otisky. Bitcoin tím nezmění, ale izolovanému klientovi může něco zamlčet. Kontrola matematické návaznosti proto musí být doplněna ověřením, že jde o správná data. [1]
BIP 157 počítá s porovnáním více protistran a alespoň jedním poctivým zdrojem. Při neshodě může klient najít první rozdílný bod a ověřit filtr proti podkladům. Pro sestavení basic nemusí stačit samotný nový blok: potřeba jsou také skripty dřívějších výstupů, které jeho transakce utrácejí. Zvláštní péči vyžaduje reorganizace, kdy síť přejde na jinou větev platných bloků s větším souhrnným důkazem práce. Peněženka musí přepojit filtry na novou větev a upravit historii i zůstatek. Stejná výška, tedy pořadové místo v řetězci, nemusí znamenat stejný blok. [1] [3]
Peněženka potřebuje dostupné filtry i způsob, jak získat vybrané celé bloky. Uzel může staré bloky odstranit po vytvoření filtru, a pak je musí dodat někdo jiný. V Bitcoin Core příkaz getblockfilter při zapnutém odpovídajícím indexu vrací filtr a jeho hlavičku pro zadaný blok. Dostupnost příkazu ještě neznamená veřejné poskytování služby P2P, tedy ostatním uzlům, ani dostupnost celé historie. Filtry již vytvořených bloků navíc neoznamují nepotvrzené transakce v Mempool. Pro zobrazení čekající platby potřebuje aplikace další mechanismus. Právě tyto provozní detaily rozhodují, zda bude lehká peněženka skutečně dobře fungovat. [1] [4]
Pro nejúplnější obraz čtěte toto heslo společně s Compact Block Filters, Neutrino, Full Node, Soukromí v Bitcoinu, Compact Blocks, Bitcoin. Opačným směrem na něj odkazují také Neutrino, Erlay.