Wenn ein Miner einen Block findet, zählt Geschwindigkeit. Je länger ein Block braucht, um andere Miner zu erreichen, desto wahrscheinlicher konkurrieren zwei Blöcke, und langsame Propagation begünstigt große, gut vernetzte Miner. Dabei sind die meisten Transaktionen in einem neuen Block schon im Mempool jedes Nodes. BIP152 von Matt Corallo vermeidet, sie zweimal zu senden. Bitcoin Core unterstützt es seit Version 0.13.0 im Jahr 2016.
Was gesendet wird
Ein Compact Block enthält den 80-Byte-Header, eine Zufalls-Nonce, eine Liste 6-Byte-kurzer Transaktions-IDs und einige „vorgefüllte“ Volltransaktionen, zumindest die Coinbase-Transaktion. Kurze IDs kommen von SipHash-2-4, geschlüsselt mit einem Hash aus Header und Nonce, sodass ein Angreifer sie nicht vorab vorhersagen kann, um Kollisionen zu erzeugen.
Den Block neu aufbauen
Der Empfänger berechnet kurze IDs für seine eigenen Mempool-Transaktionen und matched sie. Fehlt etwas, fragt er mit getblocktxn und erhält ein blocktxn. Eine Kurz-ID-Kollision ist möglich, aber selten. Dann fällt der Node auf den Download des ganzen Blocks zurück.
Zwei Modi
- Niedrige Bandbreite: Der Peer kündigt den Block wie üblich nach der Validierung an, und der Empfänger fordert die kompakte Version an. Das braucht 1,5 Roundtrips, oder 2,5 wenn Transaktionen fehlen, nutzt aber weit weniger Bandbreite als zuvor.
- Hohe Bandbreite: Der Peer schickt den Compact Block sofort, auch bevor er ihn vollständig validiert. Fehlt nichts, braucht es gar keinen Extra-Roundtrip. Bitcoin Core wählt bis zu 3 Peers für diesen Modus.
Versionen
Version 1 nutzt TxIDs. Version 2 nutzt WtxIDs, sodass die kurzen IDs auch Witness-Daten abdecken. Moderne Nodes nutzen Version 2.
Warum es zählt
Schnellere, leichtere Block-Weiterleitung senkt den Anteil veralteter Blöcke und macht den Betrieb eines Full Nodes günstiger. Sie verringert auch den Vorsprung großer Miner durch schnelle Relay-Netze.