Glossar / Entwicklerreferenz
MSG_FILTERED_WITNESS_BLOCK
- Was ist MSG_FILTERED_WITNESS_BLOCK?
- Der gefilterte Witness-Block-Typ steht in der reservierten Liste von BIP144 und im Quelltext-Enum von Bitcoin Core, ohne dass an einer der beiden Stellen eine Implementierung dahintersteht.
Spezifiziert im BIP-144.
MSG_FILTERED_WITNESS_BLOCK ist der Inventarcode 0x40000003, reserviert, als 2016 die Peer-Regeln für SegWit geschrieben wurden, und nie implementiert. Bitcoin Core führt ihn als Enum-Eintrag mit einem Kommentar, der genau das festhält. Die Light-Wallet-Funktion, die er erweitert hätte, das Bloom-Filtering von BIP37, wurde in Bitcoin Core 0.19.0 standardmäßig abgeschaltet, was für Sie nur dann von Bedeutung ist, wenn die Wallet auf Ihrem Smartphone noch darauf setzt.
So funktioniert es
Status: reserviert und nie gebaut. BIP144 gab dem Typ seinen Namen; Bitcoin Core führt ihn als Enum-Eintrag in src/protocol.h mit einem Kommentar, der festhält, dass kein Handler existiert. Das BIP37-Filtering, dem er gedient hätte, ist seit Bitcoin Core 0.19.0 im November 2019 standardmäßig deaktiviert, und die kompakten Blockfilter aus BIP157 und BIP158 sind der Ersatz.
Die Lücke versteht nur, wer versteht, was ein gefilterter Block war. Ein Light Client, der BIP37 nutzt, sendet eine filterload-Nachricht, die grob die Adressen beschreibt, die für ihn relevant sind. Danach fordert er den Inventartyp 3 an, MSG_FILTERED_BLOCK, und der bedienende Node antwortet mit einer merkleblock-Nachricht: dem 80 Byte großen Blockheader, einer Transaktionsanzahl, einem partiellen Merkle-Zweig und einem Bitfeld, das angibt, wie der Baum zu durchlaufen ist. Die passenden Transaktionen folgen als separate Nachrichten. Der Client prüft, dass jede von ihnen tatsächlich an der Merkle-Wurzel des Headers hängt, und das allein anhand der txids.
Witnesses gingen nie in diese Rechnung ein. Da die Merkle-Wurzel aus txids gebildet wird, kann ein Light Client die Zugehörigkeit ohne eine einzige Signatur beweisen, deshalb wurden die nachfolgenden Transaktionen ohne Witness-Daten gesendet. Der reservierte Typ, also 3 mit gesetztem Witness-Flag, 0x40000003, hätte es einem Client erlaubt, diese Transaktionen vollständig anzufordern. Niemand hat ihn gebaut, weil niemand, der Light Wallets produzierte, mehr BIP37 wollte.
Der Grund ist der Datenschutz, nicht der Aufwand. Der Filter, den ein Client hochlädt, verrät dem bedienenden Node grob, welche Adressen zu ihm gehören, und Untersuchungen bis Mitte der 2010er Jahre zeigten, dass diese Filter weit mehr preisgaben als beabsichtigt. Die Antwort von Bitcoin Core war, sie nicht mehr standardmäßig zu bedienen, statt das Design zu reparieren. BIP158 kehrt den Ablauf um: Der Node baut einen kleinen Golomb-kodierten Filter pro Block, abgestimmt auf eine Falsch-Positiv-Rate von eins zu 784.931, und veröffentlicht ihn. Der Client lädt die Filter herunter, prüft sie lokal und lädt nur bei einem Treffer einen ganzen Block, sodass der Server nichts darüber erfährt, welche Adressen von Interesse waren.
Wo Sie es sehen
Nahezu nirgends, und das ist die ehrliche Antwort für jeden, der MSG_FILTERED_WITNESS_BLOCK in einer Referenztabelle findet.
Durchsuchen Sie Bitcoin Core mit grep nach der Konstante, finden Sie einen einzigen Enum-Eintrag. Alternative Implementierungen wie btcd spiegeln den Namen in ihren Wire-Paketen der Vollständigkeit halber, wieder ohne Verhalten dahinter. Keine Wallet hat ihn je gesendet.
Wo das Thema einen Käufer tatsächlich berührt, ist die Frage, wie eine mobile Wallet an ihre Daten kommt. Wenn eine Wallet sich als SPV bezeichnet und sich mit Bloom-Filtern mit zufälligen öffentlichen Nodes verbindet, nutzt sie einen Mechanismus, den die Referenzimplementierung seit Jahren nicht mehr standardmäßig bedient, und sie verrät diesen Nodes etwas über Ihre Adressen. Wallets, die auf kompakten Blockfiltern aufbauen, dem Design hinter Neutrino von lnd, verlangen weit weniger. Eine Wallet, die auf den Server ihres eigenen Anbieters zeigt, ist die dritte Option und die häufigste: schnell, privat gegenüber Fremden und für den Anbieter vollständig sichtbar.
MSG_FILTERED_WITNESS_BLOCK vs. Merkle-Block
Ein Merkle-Block ist die Antwort; MSG_FILTERED_WITNESS_BLOCK ist eine Anfrage, die nie verdrahtet wurde, um einen zu erzeugen. Die merkleblock-Nachricht ist eine reale, implementierte Struktur, die beweist, dass eine Gruppe von Transaktionen zu einem Block gehört, ohne den Block zu senden. Die reservierte Witness-Variante hätte nur geändert, was nach diesem Beweis kam, nämlich ob die passenden Transaktionen mit ihren Signaturen eintrafen. Da Inklusionsbeweise mit txids arbeiten, kostete die fehlende Funktion niemanden etwas.