Das Papier On the Privacy Provisions of Bloom Filters in Lightweight Bitcoin Clients hat Folgendes über Bloom-Filter in SPV zu sagen:
... Tatsächlich werden in aktuellen Implementierungen von SPV-Clients [BitcoinJ] sowohl die Adressen als auch ihre öffentlichen Schlüssel in den ausgelagerten Bloom-Filter eingefügt. Wenn der Gegner sowohl die Adresse als auch seinen öffentlichen Schlüssel kennt, kann er somit trivial testen, ob eine Adresse ein wahrer positiver Wert des Filters ist, indem er überprüft, ob sowohl die Adresse als auch sein öffentlicher Schlüssel in den Filter eingefügt werden. Wenn nicht, dann ist es sehr wahrscheinlich, dass die Adresse ein falsches Positiv des Filters ist. Wir glauben, dass die Einbeziehung sowohl der Adresse als auch ihres öffentlichen Schlüssels in den Bloom-Filter einen schwerwiegenden Fehler in den aktuellen SPV-Client-Implementierungen darstellt – und leicht behoben werden kann; wir nutzen diesen Fehler daher in unserer Analyse nicht aus. Tatsächlich bestehen mehr als 99 % aller Bitcoin-Transaktionen aus Zahlungen an Bitcoin-Adressen (oder den Public-Key-Hash); Darüber hinaus erhielten nur 4587 von insgesamt 33 Millionen Adressen im System Transaktionen, die sowohl für ihre öffentlichen Schlüssel als auch für ihre öffentlichen Schlüssel-Hashes bestimmt waren. Das bedeutet, dass es für die überwiegende Mehrheit der Bitcoin-Kunden nicht notwendig ist, sowohl die öffentlichen Schlüssel als auch ihre Hashes (dh die Bitcoin-Adressen) in die Bloom-Filter aufzunehmen; das Einfügen des einen oder anderen würde ausreichen (in mehr als 99 % der Fälle). [meine Betonung]
Die Idee hinter diesem Angriff wurde in Privacy in BitcoinJ wiederholt :
Die Schwachstelle besteht darin, dass, wenn sich ein Pubkey wirklich im Filter befindet, die Abfrage sowohl von Pubkey als auch von Pubkeyhash „true“ zurückgeben muss. Da der Pubkeyhash nur eine weitere, fast gleichmäßig zufällige Zeichenfolge ist, beträgt die Wahrscheinlichkeit eines Fehlalarms für den Angreifer fp' = fp^2 = 0,0000000021555. Ich habe rund 56 Millionen Pubkeys aus der Blockchain erhalten (Mitte Januar), was theoretisch 56 Millionen * fp' = 1,29 erwartete Fehlalarme beim Scannen der Blockchain ergibt.
Mit anderen Worten, ein einfacher Angriff reicht aus, um alle öffentlichen Schlüssel aus einem BitcoinJ Bloom-Filter herauszusuchen.
Fügt die aktuelle Version von BitcoinJ sowohl einen öffentlichen Schlüssel als auch seinen Hash-Wert zu seinen Bloom-Filtern hinzu? Wenn nicht, welche Veröffentlichung hat es verhindert?
Warum wurden überhaupt sowohl öffentliche Schlüssel als auch Hashes hinzugefügt?
Fügt die aktuelle Version von BitcoinJ sowohl einen öffentlichen Schlüssel als auch seinen Hash-Wert zu seinen Bloom-Filtern hinzu? Wenn nicht, welche Veröffentlichung hat es verhindert?
Ja. Der folgende Code implementiert es:
/** Inserts the given key and equivalent hashed form (for the address). */
public synchronized void insert(ECKey key) {
insert(key.getPubKey());
insert(key.getPubKeyHash());
}
Warum wurden überhaupt sowohl öffentliche Schlüssel als auch Hashes hinzugefügt?
Ich bin nicht der Typ, der das geschrieben hat (Mike Hearn). Allerdings würde ich vermuten, dass es schwierig ist zu sagen, ob Einzahlungen an eine Adresse in P2PKH- oder P2PK-Form erfolgen. Pay to Public Key ist wirklich ungewöhnlich, aber es ist legal. Vor die Wahl gestellt, einen Teil des Geldes seiner Kunden aus mysteriösen Gründen verschwinden zu lassen oder ihre Privatsphäre einzuschränken, entschied er sich für Letzteres.
Wenn Sie sich jetzt fragen, warum filterloadnicht einfach der HASH160 eines Schlüssels genommen wird, bevor Sie ihn mit dem Bloom-Filter vergleichen, damit ein Thin Client gleichzeitig nach dem Hash und dem Schlüssel suchen kann, weiß ich nicht. Das scheint, als würde es das in diesem Dokument erwähnte Problem für eine ziemlich angemessene Menge an CPU-Zeit beheben. Ich würde dem Autor von BIP37 die Schuld geben , aber das wurde von demselben Typen geschrieben.
Wenn ein SPV-Kunde sein Wallet-Guthaben überwachen möchte, muss er sowohl eingehende Gelder verfolgen – Transaktionen mit Ausgaben, die den Hash des öffentlichen Schlüssels der Brieftasche (die Bitcoin-Adresse) enthalten, als auch die ausgehenden Gelder – Transaktionen mit Eingaben, in denen der öffentliche Schlüssel der Brieftasche enthalten ist ihr Signaturskript. (Natürlich muss der SPV-Client alle Pub Keys / Adressen überwachen, die das Wallet generiert hat.)
Man könnte sagen, dass das Verfolgen der ausgehenden Gelder die automatische Aktualisierungsfunktion des Bloom-Filters dupliziert, aber ich denke, der Anwendungsfall hier ist eine SPV-Synchronisierung von einer beliebigen Blockhöhe.