Compact Block Filters

Anna öffnet nach längerer Zeit ihre Handy-Wallet. Die Anwendung muss herausfinden, ob seit der letzten Verbindung Geld eingegangen ist oder Mittel ausgegeben wurden. Statt aller Transaktionen lädt sie kleine Filter und vergleicht sie mit den Bedingungen der beobachteten Outputs. Ein Output ist der Teil einer Transaktion, der einen Betrag und dessen Ausgabebedingungen festlegt. Bei einem Treffer fordert die Wallet den ganzen Block an und sucht die tatsächliche Transaktion. Den Saldo darf sie nicht allein wegen eines Filtertreffers erhöhen. Ein Filter ist weder Kontoauszug noch Eigentumsnachweis. Vor der Suche synchronisiert der Client die Blockheader, also kurze identifizierende Blockdaten, und die miteinander verknüpften Filterheader. [1]

Beim älteren Verfahren BIP 37 schickte der Client einer Gegenstelle einen Filter aus den Daten, die er beobachten wollte. Hier ist die Richtung umgekehrt: Der Server liefert den Blockfilter, Anna sucht lokal. Für denselben Block und Filtertyp erhalten Clients denselben Inhalt. Ihre gesuchten Skripte müssen sie daher nicht direkt jedem Server verraten. Anonymität entsteht daraus nicht: Die Gegenstelle kann weiterhin IP-Adresse, Verbindungszeiten und später angeforderte vollständige Blöcke sehen. Downloads auf verschiedene Gegenstellen zu verteilen begrenzt die Informationen bei einer einzelnen, beseitigt aber nicht alle Verknüpfungsmöglichkeiten. [1]

Compact Block Filters wählen Blöcke zur näheren Prüfung aus. Compact Blocks nach BIP 152 lösen ein anderes Problem: Sie sparen beim Blockversand Daten durch kurze Kennungen für Transaktionen, die der Empfänger häufig schon kennt. Er nutzt dafür seinen Mempool, den lokalen Bestand unbestätigter Transaktionen, und fordert Fehlendes nach. Keines der Verfahren prüft allein sämtliche Bitcoin-Regeln. Ein Full Node, also ein vollständiger Knoten, validiert Blöcke und Transaktionen selbstständig anhand der Netzwerkregeln. Eine leichte Wallet, die nur Header und die Aufnahme ihrer Transaktion prüft, führt eine begrenztere Kontrolle durch. Datenersparnis und vollständige Validierung sind verschiedene Eigenschaften. [1] [5]

BIP 158 beschreibt das Format. Der Filter basic enthält den scriptPubKey, das Skript mit den Ausgabebedingungen, neuer Outputs außer solchen, die mit OP_RETURN beginnen. Hinzu kommen die Skripte früherer Outputs, die im Block ausgegeben werden. Bei den Inputs ist die coinbase ausgenommen, die erste Transaktion des Blocks zur Verteilung der Miner-Vergütung, die keine gewöhnlichen früheren Outputs ausgibt. Ihre neuen Outputs unterliegen denselben Aufnahmeregeln wie andere neue Outputs. Leere Einträge entfallen. Eine Wallet muss eine Adresse in das richtige Skript umwandeln; nach dem gedruckten Adresstext zu suchen reicht nicht. Der Filter ist keine allgemeine Suchmaschine für txid-Transaktionskennungen, Witness-Daten wie Signaturen oder beliebige Notizen. [2] [3]

Nach dem Download stellt Anna möglicherweise fest, dass der Block nichts mit ihr zu tun hat. Ein solcher falscher Treffer ist der übliche Preis eines kleinen Filters und allein kein Fehlerbeweis. Technisch werden Einträge auf Zahlenwerte abgebildet, sortiert und ihre Differenzen mit Golomb-Rice-Codierung platzsparend gespeichert. Für basic gelten P=19 und M=784931. Eine einzelne Abfrage nach einem nicht enthaltenen Eintrag ergibt mit einer Wahrscheinlichkeit von ungefähr 1/M einen Treffer; mehr beobachtete Einträge schaffen mehr Gelegenheiten für Treffer. Das ist keine feste Fehlerquote der gesamten Wallet. Ein korrekt erzeugter Filter übersieht einen enthaltenen Eintrag nicht. Ein negatives Ergebnis ist aber nur bei korrektem Filter, erfasstem Datentyp und richtiger Abfrage verlässlich. [2]

BIP 157 regelt die Übertragung und die verknüpften Filterheader. Jeder Header verbindet den Hash, einen kryptografischen Fingerabdruck des aktuellen Filters, mit dem vorherigen Header. Eine Filteränderung durchbricht die erwartete Verknüpfung. Diese Kette ist jedoch kein Bestandteil des Bitcoin-Blockheaders; ihr Inhalt wird nicht direkt durch Mining festgeschrieben. Eine unehrliche Gegenstelle kann falsche Filter samt rechnerisch passenden Fingerabdrücken vorbereiten. Sie verändert damit Bitcoin nicht, kann einem isolierten Client aber Informationen vorenthalten. Zur Prüfung der mathematischen Verknüpfung muss deshalb die Prüfung der zugrunde liegenden Daten kommen. [1]

BIP 157 setzt auf den Vergleich mehrerer Gegenstellen mit mindestens einer ehrlichen Quelle. Bei Widersprüchen kann der Client die erste Abweichung finden und den Filter anhand der Ausgangsdaten prüfen. Für die Erstellung von basic reicht der neue Block allein möglicherweise nicht: Benötigt werden auch Skripte früherer Outputs, die seine Transaktionen ausgeben. Eine Reorganisation verlangt besondere Behandlung: Das Netzwerk wechselt auf einen anderen Zweig gültiger Blöcke mit mehr kumulierter Arbeitsleistung. Die Wallet muss Filter an den neuen Zweig anbinden und Verlauf sowie Saldo aktualisieren. Dieselbe Höhe, also Position in der Kette, bezeichnet nicht zwingend denselben Block. [1] [3]

Eine Wallet braucht verfügbare Filter und einen Weg zu den ausgewählten vollständigen Blöcken. Ein Knoten kann alte Blöcke nach der Filtererstellung löschen; dann muss eine andere Quelle sie liefern. In Bitcoin Core gibt getblockfilter bei aktiviertem passenden Index den Filter und seinen Header für einen bestimmten Block zurück. Die Verfügbarkeit dieses Befehls belegt weder einen öffentlichen P2P-Dienst für andere Knoten noch den Zugriff auf die gesamte Historie. Filter vorhandener Blöcke melden außerdem keine unbestätigten Transaktionen im Mempool. Für ausstehende Zahlungen braucht die Anwendung einen weiteren Mechanismus. Solche Betriebsdetails entscheiden, ob eine leichte Wallet tatsächlich gut funktioniert. [1] [4]