Compact Block Filters

Anna wartet auf eine Zahlung in ihrer Handy-Wallet. Eine Wallet ist eine Anwendung oder ein Gerät zum Empfangen und Senden von Bitcoin. Blöcke sind Bündel von Transaktionen, doch das Telefon muss nicht jedes Bündel vollständig herunterladen. Es kann zunächst kleine Filter durchsuchen, ähnlich einem Buchregister, das auf interessante Seiten verweist. Für denselben Block und Filtertyp erhalten alle Nutzer dieselbe Zusammenfassung; was Anna betrifft, entscheidet erst ihr Telefon. Die technischen Dokumente BIP 157 und BIP 158 teilen die Aufgabe auf: Das erste beschreibt Abruf und Prüfung, das zweite Inhalt und Aufbau der Filter. Zunächst prüft die Wallet die Blockheader, also die grundlegenden Daten zur Verkettung der Blöcke. Dann folgen die Prüfdaten der Filter und die Filter selbst. Bei einem Treffer lädt sie den ganzen Block und sucht die tatsächliche Transaktion. Die ähnlich benannten Compact Blocks aus BIP 152 lösen ein anderes Problem: neue Blöcke schnell zwischen Knoten weiterzugeben. Ein Knoten ist ein Programm, das Transaktionen und Blöcke prüft und sich mit anderen Netzwerkteilnehmern austauscht. [1] [2] [5] [6]

Eine Bitcoin-Transaktion erzeugt Outputs: Beträge mit Bedingungen für ihre spätere Ausgabe. Der Code für diese Bedingungen heißt scriptPubKey. Ein Input einer neuen Transaktion verweist auf einen früheren Output, der ausgegeben wird. Der basic-Filter mit der Kennung 0x00 enthält deshalb sowohl Skripte neuer Outputs als auch die Skripte früherer Outputs, die im Block ausgegeben werden. Anna kann damit Einnahmen und Ausgaben erkennen. Ausgenommen sind neue Output-Skripte, die mit OP_RETURN beginnen, einer Anweisung für einen nicht ausgebbaren Output. Ebenfalls ausgenommen ist der besondere Input der coinbase-Transaktion, die dem Miner seine Vergütung zuweist, ohne einen früheren Output auszugeben. Leere Einträge entfallen, wiederholte Einträge zählen nur einmal. Der Filter ist keine Liste aller Transaktionskennungen txid, Adresszeichenfolgen oder witness-Daten wie Signaturen. Zu seiner korrekten Erstellung braucht man neben dem neuen Block auch die darin ausgegebenen früheren Outputs. [2]

Ein Server könnte Anna eine Zusammenfassung schicken, die ihre Zahlung absichtlich auslässt. Die Wallet prüft deshalb auch die Verbindung zu früheren Filtern. Ein Hash ist ein kurzer digitaler Fingerabdruck von Daten. Zweimaliges Anwenden von SHA-256 auf den gespeicherten Filter ergibt seinen double-SHA256-Hash. Dieser wird mit dem vorherigen Filterheader verbunden und erneut so gehasht; das Ergebnis ist der nächste Header. Ändert man einen älteren Filter, ändern sich damit auch die nachfolgenden Prüfdaten. Der durch Mining geschützte Blockheader enthält jedoch keinen Hash dieser zusätzlichen Filterkette. Liefern alle verbundenen Server dieselbe falsche Kette, können ihre Fingerabdrücke trotzdem fehlerfrei zusammenpassen. Mathematische Konsistenz allein beweist nicht, dass die Zusammenfassung dem echten Block entspricht. [1]

BIP 157 empfiehlt daher Verbindungen zu mehreren unabhängigen Knoten, in dieser Kommunikation Peers genannt. Alternativ kann eine sichere Verbindung zu einem vertrauenswürdigen, etwa dem eigenen Knoten genutzt werden. Bei widersprüchlichen Filterketten sucht die Wallet die erste Abweichung. Aus dem betreffenden Block und den benötigten früheren Outputs kann sie den richtigen Filter neu berechnen. Die Zusicherung, korrekte Filter zu erkennen, setzt mindestens einen ehrlichen Peer voraus; mehrere Verbindungen zum selben Angreifer genügen nicht. Auch die Blockchain kann sich ändern: Bei einer Reorganisation ersetzen Knoten einen Teil ihres Endes durch einen Zweig mit mehr angesammelter nachgewiesener Arbeit. Die Wallet muss dessen Filtern folgen und betroffene Zahlungen neu bewerten. Eine bereits gefundene Bestätigung hängt weiterhin davon ab, welche Kette das Netzwerk akzeptiert. [1] [2]

Beim älteren Verfahren BIP 37 schickte die Wallet dem Server einen persönlichen Filter ihrer gesuchten Daten. Compact Block Filters kehren den Ablauf um: Die Wallet lädt allgemeine Daten und trifft die persönliche Auswahl auf dem eigenen Gerät. Dadurch verrät sie weniger über beobachtete Skripte. Der Anbieter sieht allerdings weiterhin, welche vollständigen Blöcke Anna anschließend anfordert, und kann dies mit ihrer IP-Adresse, der Netzwerkadresse ihrer Verbindung, verknüpfen. Wiederholte Abrufe können weitere Muster offenlegen. BIP 157 empfiehlt deshalb, ganze Blöcke von zufällig ausgewählten Knoten zu beziehen, zu denen die Wallet selbst Verbindungen aufgebaut hat. Block und Filter dürfen von verschiedenen Knoten kommen. Das verbessert den Datenschutz, garantiert aber keine Anonymität. [1]

Filter beschreiben bereits in die Blockchain aufgenommene Blöcke. Sie bilden nicht den aktuellen Mempool ab, also die unbestätigten Transaktionen, die ein bestimmter Knoten zur Weitergabe oder zum Mining bereithält. Ein Treffer beweist auch nicht, dass Anna den zum Ausgeben nötigen Schlüssel besitzt. Ein privater Schlüssel ist ein geheimer Zahlenwert, mit dem die Wallet eine digitale Signatur zur Freigabe einer Ausgabe erstellt. Die Wallet muss die tatsächliche Transaktion und ihre Aufnahme in den Block prüfen. Ein leichter Client prüft dennoch nicht jede Transaktion jedes Blocks nach sämtlichen Regeln, wie ein Full Node es tut. Die Ressourcenersparnis hat also eine echte Sicherheitsgrenze. Davon zu unterscheiden ist die Verfügbarkeit: Ein Pruned Node kann alte Blöcke nach ihrer Prüfung löschen und die Filter behalten. Anna erhält dann die Zusammenfassung, muss den vollständigen alten Block aber anderswo anfordern. Pruning allein bedeutet nicht, dass der Knoten auf vollständige Regelprüfung verzichtet. [1] [5]

Die geringe Größe hat einen Preis: Der Filter kann „möglicherweise ja“ antworten, obwohl der gesuchte Eintrag nicht im Block vorkommt. Das ist ein False Positive, ein Fehlalarm. Anna lädt dann unnötig einen Block; ihre Wallet findet darin aber keine entsprechende Zahlung und darf sie nicht anrechnen. Ein korrekter Filter übersieht keinen Eintrag, den seine Regeln tatsächlich einschließen. Diese Eigenschaft macht erfundene Daten eines unehrlichen Servers nicht zuverlässig. Technisch bildet SipHash-2-4 die Einträge auf Zahlen in einem Bereich der Größe N × M ab; N ist die Anzahl der Einträge. Die Zahlen werden sortiert und ihre Abstände mit Golomb-Rice-Codierung platzsparend gespeichert. P=19 steuert die Codierung. M=784931 beeinflusst zufällige Treffer; für eine einzelne Abfrage außerhalb der Menge beträgt deren Wahrscheinlichkeit ungefähr 1/M. Ein Byte ist eine übliche Einheit für Datenmengen. Als SipHash-Schlüssel dienen die ersten 16 Bytes des Blockhashs in little-endian-Reihenfolge, also mit den niederwertigen Bytes zuerst. Das ist kein geheimer Wallet-Schlüssel. SipHash bildet die Einträge hier auf Zahlen für den Filter ab, statt sie zu verschlüsseln. Die gespeicherte Datei beginnt mit N im CompactSize-Format für nichtnegative ganze Zahlen. [2]

Zum Prüfdatum 2026-10-17 haben beide Dokumente den Status Deployed: Das Protokoll ist im Einsatz, wird aber nicht zwangsläufig von jeder Wallet unterstützt. Das folgende Konfigurationsbeispiel bezieht sich ausdrücklich auf Bitcoin Core 29.0. -blockfilterindex erstellt einen lokalen Filterindex. Erst -peerblockfilters aktiviert die Bereitstellung für andere Knoten und benötigt dafür einen basic-Index; NODE_COMPACT_FILTERS signalisiert die Unterstützung. Über die RPC-Programmierschnittstelle liefert getblockfilter die Felder filter und header eines gewählten Blocks. Eine funktionierende RPC-Abfrage belegt deshalb noch keinen Filterdienst für andere Netzwerkknoten. Wer die Spezifikation liest, findet getcfilters/cfilter für Filter, getcfheaders/cfheaders für Verkettungsdaten und getcfcheckpt/cfcheckpt für Kontrollpunkte der Hilfskette. Das sind Namen von Netzwerknachrichten, keine Befehle für die Nutzer einer Handy-Wallet. [3] [4]