Bloom-Filter

Das Design tauschte Bandbreite gegen etwas ein, von dem seine Autoren hofften, es sei Privatsphäre, und die Privatsphäre kam nie an. Bitcoin Core stellte das Bedienen dieser Filter in Version 0.19.0, veröffentlicht im November 2019, standardmäßig ein, nachdem jahrelange Forschung gezeigt hatte, wie viel sie preisgeben. Eine Wallet, die sich noch auf einen verlässt, übergibt der Maschine eines Fremden eine brauchbare Liste der Bitcoin, die Sie besitzen.

Wie er funktioniert

Status: Die Bloom-Filterung nach BIP37 wurde in Bitcoin Core 0.19.0 im November 2019 standardmäßig abgeschaltet, und die kompakten Blockfilter nach BIP157 und BIP158 übernahmen die Aufgabe der Light Wallets.

Ein Bloom-Filter ist ein Array aus Bits plus eine Handvoll Hash-Funktionen. Um ein Element einzufügen, hashen Sie es auf mehrere Arten, nehmen jedes Ergebnis modulo der Array-Länge und setzen diese Bits auf eins. Um ein Element zu prüfen, hashen Sie es auf dieselben Arten und sehen nach. Ist eines dieser Bits null, wurde das Element mit Sicherheit nie eingefügt; sind alle eins, wurde das Element wahrscheinlich eingefügt, oder andere Einfügungen haben zufällig dieselben Bits gesetzt. Falsch negative Ergebnisse kann es nicht geben. Falsch positive schon, und ihre Rate ist die Stellschraube.

BIP37 legte die Arithmetik fest. Ein Filter ist auf 36.000 Bytes und 50 Hash-Funktionen begrenzt, und gehasht wird mit Version 3 der 32-Bit-Murmur-Funktion, initialisiert mit der Hash-Nummer multipliziert mit 0xFBA4C795 plus einem vom Client gewählten Tweak. Drei Nachrichten steuern das: filterload installiert einen Filter auf der Verbindung, filteradd erweitert ihn, filterclear entfernt ihn. Ist ein Filter gesetzt, beantwortet der Peer eine Blockanfrage mit einem merkleblock, der den 80-Byte-Header, die passenden Transaktionen und die Merkle-Zweige trägt, die belegen, dass sie zu diesem Block gehören. BIP111 fügte später ein NODE_BLOOM-Dienstbit hinzu, damit ein Node bekannt geben konnte, ob er überhaupt mitspielt.

Die ganze Geschichte der Privatsphäre ruhte auf dieser Rate falsch positiver Treffer. Machen Sie den Filter weiter, fangen Sie fremde Transaktionen neben Ihren eigenen ein, und ein Beobachter soll angeblich nicht erkennen können, welche welche sind. Das hält nicht. Im Jahr 2014 veröffentlichte akademische Arbeiten zeigten, dass ein Filter mit einer realistischen Zahl von Adressen die meisten davon preisgibt und dass zwei von derselben Wallet geladene Filter geschnitten werden können, um die Tarnung zu entfernen. Die erneute Verbindung zu einem frischen Peer mit einem neuen Filter verschlimmert das Problem, statt es zu lindern.

Der andere Fehler war billiger zu erklären. Einen Filter zu bedienen bedeutet, Blöcke auf Anweisung eines Fremden von der Festplatte zu scannen, sodass jeder Peer einen Node mit rotierender Festplatte zu einer enormen Menge unbezahlter Arbeit zwingen konnte. Mit diesem Argument der Dienstverweigerung, nicht mit der Forschung zur Privatsphäre, beginnen die Versionshinweise zu 0.19.0.

Wo er auftaucht

Bloom-Filter überleben vor allem in Software, die vor 2019 geschrieben wurde, und in Konfigurationsdateien, die ihr Fehlen umgehen.

Android-Wallets, die auf der Bibliothek bitcoinj aufbauten, nutzten BIP37 als einziges Chain-Backend, und einige sind noch installiert. Bisq brauchte es ebenfalls, weshalb seine Dokumentation früher dazu anleitete, peerbloomfilters=1 zur Konfiguration des eigenen Nodes hinzuzufügen. Diese Zeile ist das Verräterische: Wenn ein Programm Sie bittet, die Bloom-Filterung auf einem Node, den Sie betreiben, wieder zu aktivieren, bittet es um eine Technik, die der Referenz-Client aus guten Gründen abgeschaltet hat.

Der moderne Ersatz funktioniert andersherum. Nach BIP157 und BIP158 baut der Node einen Filter pro Block und veröffentlicht ihn für alle, und die Wallet gleicht auf ihrer eigenen Hardware ab, sodass nichts über Ihre Adressen das Gerät verlässt.

Bloom-Filter vs. SPV

Ein Bloom-Filter war ein Auslieferungsmechanismus; die vereinfachte Zahlungsverifizierung ist ein Vertrauensmodell, und beide zu vermischen lässt Menschen annehmen, das Modell sei mit dem Mechanismus gestorben. SPV bedeutet zu prüfen, dass eine Transaktion unter der Merkle-Wurzel eines Headers in der Chain mit der meisten Arbeit liegt, ohne den restlichen Inhalt dieser Chain zu validieren. Diese Logik ist unverändert. Geändert hat sich, wie eine Light Wallet die prüfenswerten Transaktionen findet: Früher sendete sie eine verlustbehaftete Skizze ihrer eigenen Adressen und hoffte, jetzt lädt sie einen Filter pro Block herunter und prüft ihn zu Hause.