Glossaire / Référence pour développeurs
MSG_WITNESS_BLOCK
- Qu'est-ce que MSG_WITNESS_BLOCK ?
- Le type d'inventaire witness block est la façon dont un nœud compatible segwit demande un bloc dans la sérialisation étendue, avec toutes les signatures attachées au lieu d'être retirées.
Spécifié dans BIP-144.
Deux nœuds peuvent détenir le même bloc et ne pas être d'accord sur son nombre d'octets. MSG_WITNESS_BLOCK est le code 0x40000002, une demande de bloc ordinaire à laquelle s'ajoute le bit witness, et il existe depuis l'activation de segregated witness au bloc 481 824 le 24 août 2017. Si vous exploitez votre propre nœud, c'est la demande qui récupère les signatures dont votre machine a besoin avant de faire confiance à la chaîne.
Comment cela fonctionne
Bitcoin Core conserve deux façons d'écrire un même bloc et choisit entre elles selon qui demande.
Le drapeau witness est un seul bit de poids fort, 0x40000000. Ajoutez-le au type d'inventaire de bloc, qui est 2, et vous obtenez 0x40000002. Le BIP144 a introduit à la fois ce drapeau et le bit de service NODE_WITNESS, de valeur 8, qu'un nœud annonce dans son message version pour dire qu'il peut servir les données plus complètes. Le drapeau n'apparaît jamais que dans une demande getdata. Les annonces circulent sous forme d'inventaires de bloc ordinaires, car une annonce n'est qu'un hash et le hash est le même dans les deux cas.
Ce dernier point explique pourquoi deux sérialisations peuvent coexister. Un en-tête de bloc engage un merkle root construit à partir des txid, et un txid est calculé sur la transaction privée de son witness. Retirez toutes les signatures et le bloc produit toujours le même identifiant de 32 octets. Les données witness sont engagées séparément, dans une sortie de la transaction coinbase dont le script fait au moins 38 octets et commence par l'étiquette de quatre octets 0xaa21a9ed suivie d'un merkle root witness de 32 octets.
C'est sur la taille que la différence se fait sentir. La limite d'un bloc est de 4 000 000 unités de poids, comptées comme trois fois la taille dépouillée plus la taille complète, ce qui permet à un bloc chargé de données witness d'approcher 4 Mo sur le réseau. Le bloc 774 628, miné le 1er février 2023, est arrivé à environ 3,96 Mo, presque entièrement occupé par une seule inscription logée dans l'espace witness. Si l'on inverse cette formule de poids, un bloc de cette taille n'a presque plus rien sous sa forme dépouillée. Un ancien pair demandant la sérialisation héritée aurait reçu le squelette et aucun contenu, ce qui explique précisément pourquoi ces pairs sont considérés comme incapables de valider les blocs actuels.
Où le voir
Deux endroits rendent MSG_WITNESS_BLOCK visible sans lire de code source : les journaux d'un nœud et ses statistiques de pairs.
Lancez bitcoind avec la catégorie de débogage net et des lignes getdata défilent pendant tout le téléchargement initial de la chaîne, toutes marquées witness, car un nœud moderne ne récupère des blocs qu'auprès de pairs compatibles witness. La RPC getpeerinfo ventile les octets envoyés et reçus par type de message, ce qui permet de voir facilement le trafic de blocs dominer une synchronisation. Bitcoin Core 23.0 a ajouté getblockfrompeer, qui demande à un pair nommé un bloc précis par son hash, et il récupère la forme witness.
Les nœuds élagués compliquent le tableau. Un nœud fonctionnant avec l'élagage activé, dont le réglage minimal autorisé est de 550 MiB, annonce NODE_NETWORK_LIMITED et ne sert que les 288 blocs les plus récents, soit environ deux jours d'historique. Demandez-lui quelque chose de plus ancien et rien ne revient.
Pour qui achète et conserve du bitcoin, la signification est nette. Vérifier la chaîne soi-même suppose de télécharger chaque signature et de la contrôler. Un portefeuille mobile qui interroge un serveur n'envoie jamais cette demande, ne voit jamais de witness et se fie à la parole d'un tiers pour le solde affiché à l'écran.
MSG_WITNESS_BLOCK vs MSG_BLOCK
MSG_BLOCK demande le même bloc avec les signatures retirées, et c'est désormais une demande héritée. Les deux types désignent un bloc par le même hash, et les deux reçoivent une réponse sous forme de message block. La différence tient à la présence des octets de marqueur et de drapeau et des piles witness dans chaque transaction. Un nœud qui demande MSG_BLOCK pour un bloc récent ne peut vérifier aucune dépense segwit qu'il contient, c'est pourquoi Bitcoin Core réserve cette forme aux pairs qui n'ont jamais signalé NODE_WITNESS.