Glossaire / Référence pour développeurs
MSG_TX
- Qu'est-ce que MSG_TX ?
- MSG_TX marque une entrée d'inventaire comme une transaction, code de type 1, et c'est ainsi que votre paiement non confirmé est annoncé aux pairs avant que l'un d'eux ait vu son contenu.
Un seul nombre sépare un paiement d'un bloc dans le protocole d'annonce du bitcoin, et ce nombre est 1. Il voyage avec l'identifiant de 32 octets de la transaction, soit 36 octets au total, et il n'engage l'expéditeur à rien : les octets ne partent que lorsqu'un pair répond avec getdata. Depuis Bitcoin Core 0.21.0, la plupart des pairs annoncent avec un tout autre code.
Comment cela fonctionne
MSG_TX nomme une transaction par son txid, l'identifiant calculé en excluant les données de témoin.
Un nœud qui a accepté votre paiement dans sa mempool annonce à ses pairs que le hash existe. Tout pair qui ne l'a pas le demande, et c'est seulement alors que le contenu est envoyé, dans un message tx. Un pair qui demande quelque chose que le nœud ne détient plus reçoit notfound, ce qui arrive couramment : les mempools évacuent des entrées sous la pression, et un nœud ne doit à personne une copie d'une transaction qu'il a déjà abandonnée.
La fourniture est délibérément parcimonieuse. Bitcoin Core ne remettra pas une transaction à un pair auquel il ne l'a jamais annoncée avant que cette transaction n'ait séjourné quelques minutes dans la mempool. Sans ce délai, un inconnu pourrait se connecter et utiliser getdata pour vérifier si votre nœud connaît certains paiements, ce qui transformerait chaque nœud en interface d'interrogation de sa propre mempool et rendrait bien plus facile de déterminer où un paiement est apparu pour la première fois.
Le type 1 transporte aussi l'ancienne règle de sérialisation. Une transaction servie en réponse à ce type est écrite sans données de témoin, le format qui existait avant 2017, lequel omet les signatures pour une dépense segwit. Les pairs compatibles segwit demandent donc la variante avec témoin, et depuis que le BIP339 a été livré dans Bitcoin Core 0.21.0 en janvier 2021, ils annoncent normalement avec le type 5, nommant les transactions par hash de témoin afin qu'un témoin altéré ne ressemble plus à une transaction inconnue.
Où le voir
MSG_TX est la machinerie derrière l'expression « la transaction a été diffusée », et derrière les occasions où il s'avère qu'elle ne l'a pas été.
Un portefeuille connecté à un seul nœud remet une transaction signée, ce nœud annonce le hash, et rien d'autre ne se produit tant qu'un pair ne la demande pas. Si aucun ne le fait jamais, le paiement reste sur une seule machine et aucun mineur ne le verra. Bitcoin Core suit ses propres transactions de portefeuille qu'aucun pair n'a encore demandées et les annonce de nouveau jusqu'à ce qu'un pair le fasse. Un nœud sans connexions sortantes, sur un réseau domestique derrière un pare-feu, peut donc signaler un paiement comme envoyé alors que rien du tout n'a quitté les lieux.
Le regroupement des retraits de plateforme apparaît ici aussi. La plateforme annonce un seul hash, une seule demande livre une transaction payant des dizaines de clients à la fois, et c'est pourquoi le txid de votre retrait contient des sorties appartenant à des inconnus.
MSG_TX vs le message P2P tx
MSG_TX nomme une transaction, et le message tx en contient une. Les confondre rend les journaux de protocole illisibles, car les lignes inv et getdata ne sont rien d'autre que des codes de type et des hash, tandis que les octets eux-mêmes n'apparaissent que sur les lignes tx. La distinction compte surtout lorsque vous déboguez la propagation. Voir votre hash partir dans un inv prouve que votre nœud a prévenu quelqu'un. Voir un message tx suivre prouve que quelqu'un en voulait réellement.