Glossar / Entwicklerreferenz
MSG_WITNESS_BLOCK
- Was ist MSG_WITNESS_BLOCK?
- Der Inventartyp Witness-Block ist die Art und Weise, wie ein SegWit-fähiger Node einen Block in der erweiterten Serialisierung anfordert, mit allen Signaturen, die angehängt und nicht entfernt werden.
Spezifiziert im BIP-144.
Zwei Nodes können denselben Block halten und sich darüber uneinig sein, wie viele Bytes er groß ist. MSG_WITNESS_BLOCK ist der Code 0x40000002, eine gewöhnliche Blockanforderung mit zusätzlich gesetztem Witness-Bit, und existiert seit der Aktivierung von Segregated Witness in Block 481.824 am 24. August 2017. Wenn Sie einen eigenen Node betreiben, ist dies die Anforderung, die die Signaturen abruft, die Ihr Rechner benötigt, bevor er der Chain vertraut.
Wie es funktioniert
Bitcoin Core hält zwei Schreibweisen desselben Blocks bereit und wählt zwischen ihnen danach, wer fragt.
Das Witness-Flag ist ein einzelnes hohes Bit, 0x40000000. Addiert man es zum Block-Inventartyp, der 2 ist, erhält man 0x40000002. BIP144 führte sowohl dieses Flag als auch das Service-Bit NODE_WITNESS mit dem Wert 8 ein, das ein Node in seiner version-Nachricht ankündigt, um mitzuteilen, dass er die vollständigeren Daten liefern kann. Das Flag erscheint ausschließlich in einer getdata-Anforderung. Ankündigungen laufen als gewöhnliche Block-Inventare, denn eine Ankündigung ist nur ein Hash, und der Hash ist in beiden Fällen derselbe.
Der letztgenannte Punkt ist der Grund, warum zwei Serialisierungen überhaupt koexistieren können. Ein Blockheader verpflichtet sich auf eine Merkle-Wurzel, die aus txids gebildet wird, und eine txid wird über die Transaktion ohne ihren Witness berechnet. Entfernt man jede Signatur, hasht der Block weiterhin auf denselben 32-Byte-Identifikator. Die Witness-Daten werden getrennt committet, in einem Output der Coinbase-Transaktion, deren Skript mindestens 38 Byte lang ist und mit dem vier Byte großen Tag 0xaa21a9ed beginnt, gefolgt von einer 32 Byte großen Witness-Merkle-Wurzel.
Bei der Größe wird der Unterschied spürbar. Das Limit für einen Block beträgt 4.000.000 Weight Units, gezählt als dreimal die reduzierte Größe plus die volle Größe, wodurch ein mit Witness-Daten gefüllter Block auf der Leitung bis an 4 MB heranreichen kann. Block 774.628, gemint am 1. Februar 2023, kam auf rund 3,96 MB, fast alles davon eine einzelne Inscription im Witness-Bereich. Wendet man diese Weight-Formel rückwärts an, bleibt einem so großen Block in seiner reduzierten Form fast nichts übrig. Ein alter Peer, der die Legacy-Serialisierung anfordert, hätte das Skelett und nichts von der Nutzlast erhalten, weshalb solche Peers genau als unfähig gelten, aktuelle Blöcke zu validieren.
Wo Sie es sehen
An zwei Stellen wird MSG_WITNESS_BLOCK sichtbar, ohne Quellcode zu lesen: in den eigenen Logs eines Nodes und in seinen Peer-Statistiken.
Starten Sie bitcoind mit der Debug-Kategorie net, und getdata-Zeilen laufen während des gesamten Initial Block Download vorbei, jede davon mit Witness-Flag, weil ein moderner Node Blöcke nur von Witness-fähigen Peers abruft. Der RPC getpeerinfo schlüsselt gesendete und empfangene Bytes nach Nachrichtentyp auf, sodass leicht zu beobachten ist, wie der Blockverkehr einen Sync dominiert. Bitcoin Core 23.0 fügte getblockfrompeer hinzu, das einen benannten Peer nach einem bestimmten Block per Hash fragt, und es ruft die Witness-Form ab.
Pruned Nodes verkomplizieren das Bild. Ein Node mit aktiviertem Pruning, dessen kleinste zulässige Einstellung 550 MiB beträgt, kündigt NODE_NETWORK_LIMITED an und liefert nur die jüngsten 288 Blöcke, etwa zwei Tage Historie. Fragen Sie ihn nach Älterem, kommt nichts zurück.
Für jemanden, der Bitcoin kauft und hält, ist die Bedeutung eindeutig. Die Chain selbst zu verifizieren bedeutet, jede Signatur herunterzuladen und zu prüfen. Eine Wallet auf dem Smartphone, die einen Server abfragt, sendet diese Anforderung nie, sieht nie einen Witness und verlässt sich auf die Aussage eines anderen zum Kontostand auf Ihrem Bildschirm.
MSG_WITNESS_BLOCK vs. MSG_BLOCK
MSG_BLOCK fordert denselben Block ohne die Signaturen an und ist heute eine Legacy-Anforderung. Beide Typen benennen einen Block über denselben Hash, und auf beide wird mit einer block-Nachricht geantwortet. Der Unterschied besteht darin, ob die Marker- und Flag-Bytes sowie die Witness-Stacks in jeder Transaktion vorhanden sind. Ein Node, der MSG_BLOCK für einen aktuellen Block anfordert, kann darin keine einzige SegWit-Transaktion verifizieren, weshalb Bitcoin Core diese Form Peers vorbehält, die NODE_WITNESS nie signalisiert haben.