Een compacte Bitcoin-blokfilter verplaatst het zoeken naar de wallet. De wallet haalt een samenvatting van een blok op en onderzoekt zelf of daarin mogelijk relevante transacties staan. Pas bij een overeenkomst volgt het volledige blok. Daardoor hoeft de wallet haar zoekfilter niet eerst aan de node te geven die de gegevens levert.
| Wat je moet weten |
|---|
| Bij BIP157 leveren nodes blokfilters aan lichte Bitcoin-clients. |
| De wallet zoekt lokaal naar overeenkomsten met haar scripts. |
| Een filter kan een overeenkomst melden terwijl het blok niets relevants bevat. |
| Bij afwijkende filterketens kan een client het betreffende blok zelf controleren. |
Die omkering staat in de motivatie van BIP157. Bij het oudere BIP37 stuurt de client juist een Bloomfilter naar een node. Bij BIP157 maken nodes vooraf filters van blokgegevens. De zoekopdracht blijft daarmee bij de client, terwijl dezelfde blokfilter aan verschillende clients kan worden geleverd.
Dat zijn twee verschillende soorten informatie. Een blokfilter beschrijft gegevens uit een blok; de scripts waarnaar een wallet zoekt horen bij de eigen zoekopdracht. De node hoeft voor het aanleveren van die algemene filter dus niet eerst te weten welke scripts de wallet interesseren. De specificatie noemt bovendien dat de client het volledige blok bij een andere bron kan ophalen.
Een overeenkomst opent het blok
Bitcoin Optech beschrijft de vervolgstap in zijn uitleg over compacte blokfilters: de wallet vergelijkt haar scripts met de ontvangen filter en downloadt bij een overeenkomst het bijbehorende blok. De filter is probabilistisch. Er kunnen foutpositieve overeenkomsten optreden, waarbij het opgehaalde blok uiteindelijk geen voor de wallet relevante transactie bevat.
Neem een denkbeeldige wallet die bij blok A een overeenkomst vindt. Na het downloaden blijken de transacties in dat blok geen van haar scripts te raken. Dat is op zichzelf geen bewijs dat de node een verkeerde filter stuurde: een foutpositieve overeenkomst past bij het beschreven ontwerp. Het onderscheid wordt pas duidelijk wanneer de wallet het volledige blok doorzoekt. Dit voorbeeld volgt de specificatie en is geen meting aan een wallet.
Optech plaatst daar een afweging naast. De methode biedt volgens de organisatie meer privacy dan onder meer het versturen van zoekfilters bij BIP37, maar gebruikt normaal gesproken ook meer bandbreedte dan BIP37 of adresgeïndexeerde servers. Minder informatie over de zoekopdracht delen betekent dus niet automatisch minder gegevens downloaden. Er is in deze uitleg geen eigen vergelijking van dataverbruik uitgevoerd.
Wat gebeurt er bij verschillende filters?
Onder Filter Headers beschrijft BIP157 hoe filterheaders met elkaar verbonden zijn. Krijgt een client verschillende ketens van peers, dan kan hij het punt zoeken waar ze uiteenlopen. Vervolgens kan hij het volledige blok ophalen en de juiste filter berekenen om de foutieve peer aan te wijzen. Dat is een andere controle dan het nakijken van een foutpositieve overeenkomst: hier gaat het om strijdige gegevens van verschillende peers.
De specificatie verbindt de mogelijkheid om de juiste blokfilters te vinden aan ten minste één eerlijke peer. Ook schrijft zij dat lichte clients niet alle blokken volledig op geldigheid controleren. Het downloaden en controleren van blokfilters maakt een lichte wallet daardoor niet gelijk aan een volledig validerende node. BIP157 en de Optech-uitleg zijn voor dit artikel op 20 oktober 2026 geraadpleegd.
