Glossar / Nodes und Software
BIP-324 verschlüsselter Transport
Auch bekannt als v2-Transport.
- Was ist BIP-324 verschlüsselter Transport?
- Der verschlüsselte Transport nach BIP-324 ist die Version 2 des Peer-to-Peer-Verbindungsprotokolls von Bitcoin, das jede zwischen zwei Nodes ausgetauschte Nachricht verschlüsselt und die Verbindung für einen Lauscher von Zufallsdaten nicht unterscheidbar macht.
Spezifiziert im BIP-324.
Zwei Nodes, die beide BIP-324 unterstützen, führen einen Austausch ephemerer Schlüssel durch, bevor eine Bitcoin-Nachricht gesendet wird, und hüllen dann jede Nachricht in ChaCha20Poly1305. Die Spezifikation wurde am 10. Juli 2024 als final markiert, und ein Node kündigt Unterstützung mit dem Dienstflag NODE_P2P_V2 an, Bit 11. An Ihren Bitcoin ändert sich nichts: Was sich ändert, ist, dass ein passiver Beobachter die Transaktionen, die Ihr Node weitergibt, nicht mehr lesen kann.
Wie es funktioniert
BIP-324 ersetzt die festen Magic Bytes, mit denen eine Bitcoin-Verbindung früher begann, durch einen Datenstrom, der überhaupt keine erkennbare Form hat.
Die Seite, die die Verbindung aufbaut, erzeugt einen wegwerfbaren secp256k1-Schlüssel und sendet die 64-Byte-Kodierung ihres öffentlichen Schlüssels nach ElligatorSwift. Diese Kodierung ist der Kniff: Ein gewöhnlicher öffentlicher Schlüssel ist als Kurvenpunkt erkennbar, während jede 512-Bit-Zeichenkette eine gültige ElligatorSwift-Kodierung ist, sodass die Anfangsbytes statistisch bloßes Rauschen sind. Danach kann jede Seite bis zu 4095 Byte beliebiges Padding anhängen, Garbage genannt, damit eine Verbindung nicht mit genau 64 Byte beginnen muss. Beide Seiten führen X-only-ECDH aus und führen das Ergebnis durch HKDF-SHA256, um vier Verschlüsselungsschlüssel, zwei 16-Byte-Garbage-Terminatoren und eine Sitzungs-ID abzuleiten.
Diese Anfangsbytes sind der einzige Teil des Austauschs, der im Klartext gesendet wird. Nach den Terminatoren besteht alles auf der Leitung aus Paketen. Ein Paket ist ein verschlüsseltes 3-Byte-Längenfeld, gefolgt von einem ChaCha20Poly1305-Chiffretext, der einen 1-Byte-Header und den Inhalt abdeckt, mit Kosten von 20 Byte plus der Nutzlast. Das oberste Bit dieses Headers ist das Ignorierbit, und ein Paket, das es trägt, ist ein Köder: Der Empfänger bestätigt, dass es entschlüsselt wird, und verwirft es dann, und so kann ein Node seinen Datenverkehr auffüllen, um den Moment zu verschleiern, in dem eine echte Nachricht hinausging. Die Schlüssel rücken alle 224 Pakete vor, ein Intervall, das so gewählt ist, dass eine fast untätige Verbindung, die nichts als alle 20 Minuten einen Ping sendet, etwa alle 3,11 Tage die Schlüssel erneuert, und dieses Vorrücken verleiht einer Sitzung Forward Secrecy.
Das Design geht bewusst nicht so weit, zu beweisen, wer am anderen Ende sitzt. Es gibt keine Zertifikate und keine Identitäten, sodass ein entschlossener Man-in-the-Middle weiterhin zwischen zwei Nodes sitzen kann. Was er nicht kann, ist, dort billig oder unsichtbar zu sitzen: Die Sitzungs-ID fällt aus dem Schlüsselaustausch an, und zwei Betreiber, die ihre Sitzungs-IDs einander vorlesen, sehen unterschiedliche Werte, sobald jemand dazwischen sitzt.
Wo es auftaucht
BIP-324 hinterlässt nichts auf der Blockchain, sodass es nur zwischen zwei laufenden Nodes auftaucht.
Die Unterstützung wird im Adress-Gossip über das Flag NODE_P2P_V2 angekündigt, das Peers aus addr- und addrv2-Nachrichten erfahren. Diese Flags laufen über nicht vertrauenswürdige Relais und werden mit OR verknüpft, sodass eine falsche Ankündigung möglich ist, und das BIP ermutigt einen v2-Client, der sofort getrennt wird, denselben Peer über v1 erneut zu versuchen. In der anderen Richtung akzeptiert ein v2-Node weiterhin absichtlich eingehende v1-Verbindungen, damit das Netzwerk nicht in zwei Hälften zerfällt, die einander nicht erreichen können.
Der zweite sichtbare Effekt sind kürzere Nachrichten. Version 1 verbrauchte 12 ASCII-Bytes für jeden Befehlsnamen; Version 2 vergibt Ein-Byte-IDs an die 28 bisher definierten Nachrichtentypen, sodass inv das einzelne Byte 14 ist und getblocktxn 10, und jede Nachricht mit einer kurzen ID kostet 3 Byte weniger als ihre v1-Form. Alles ohne zugewiesene ID fällt auf eine 13-Byte-Kodierung zurück, ein Nullbyte gefolgt vom alten ASCII-Namen, sodass nichts verloren geht.
Die Spezifikation trägt den Status Deployed, liefert Testvektoren und eine naive Python-Referenzimplementierung, die nur zur Demonstration gedacht ist, und wird weiterhin bearbeitet: Revision 1.0.2 vom 30. Januar 2026 fügte eine Tabelle mit Nachrichtentyp-IDs in einer Hilfsdatei hinzu, damit andere BIPs IDs beanspruchen können, ohne das Hauptdokument zu ändern. Der Header hält außerdem fest, dass BIP-324 BIP-151 ersetzt.