Numéro de version de transaction

Seulement trois valeurs ont jamais eu une signification. Ce champ n'est pas une version logicielle, ni une version de protocole, ni un indice sur les types d'adresses qu'il contient, ce que la plupart des gens supposent lorsqu'ils le voient pour la première fois. Le consensus y est largement indifférent, la politique de relais non, et cet écart résume tout ce champ.

Comment cela fonctionne

La version occupe les octets 1 à 4 de la forme sérialisée, avant le nombre d'entrées, et Bitcoin Core la lit comme un entier signé de 32 bits.

La version 1 est l'originale, utilisée par toutes les transactions des premières années de la chaîne. La version 2 existe parce que le BIP68 avait besoin d'un moyen de réinterpréter les numéros de séquence comme des verrous temporels relatifs sans invalider les transactions plus anciennes, il a donc attaché ce nouveau sens à une incrémentation de version. À partir du bloc 419 328 en juillet 2016, une transaction déclarant la version 2 voit ses numéros de séquence traités comme des périodes d'attente, ce qui n'est pas le cas d'une transaction déclarant la version 1. Les portefeuilles modernes définissent la version 2 par défaut, qu'ils utilisent ou non les verrous temporels, et c'est pourquoi presque tout ce que vous consultez sur un explorateur indique 2.

La version 3 est arrivée avec Bitcoin Core 28,0 en octobre 2024, sous le nom de transactions à topologie restreinte, ou TRUC. Déclarer la version 3 revient à accepter un contrat plus strict : la transaction est toujours traitée comme remplaçable, elle peut avoir au plus un parent non confirmé et un enfant non confirmé, l'enfant est limité à 1 000 octets virtuels et la transaction elle-même à 10 000. Ces limites semblent un recul jusqu'à ce que vous ayez été épinglé, c'est-à-dire lorsqu'une contrepartie attache un descendant volumineux et peu coûteux à votre transaction non confirmée pour rendre l'augmentation des frais inabordable. Les implémentations Lightning ont adopté la version 3 pour exactement cette raison.

Aucune règle de consensus ne rejette une transaction au motif qu'elle porte la version 7, ou la version 0. Les règles de standardité s'en chargent : Bitcoin Core ne relaiera ni ne minera les versions hors de l'ensemble accepté, donc une version inhabituelle est une transaction qui doit atteindre un mineur par un autre moyen.

Où le voir

Chaque explorateur de blocs affiche la version en haut de la page de détails d'une transaction, et la commande decoderawtransaction de Bitcoin Core la renvoie comme premier champ.

Pour quiconque achète ou détient du bitcoin, c'est un élément de diagnostic plutôt qu'une décision. Vous ne la choisissez jamais, c'est votre portefeuille qui le fait. Sa valeur pratique réside dans la lecture d'un logiciel inconnu : un portefeuille qui produit encore des transactions de version 1 dans un monde de verrous temporels relatifs est ancien, et un paiement déclarant la version 3 provient presque certainement de la machinerie de canaux d'un nœud Lightning plutôt que d'une personne qui appuie sur envoyer.

Numéro de version de transaction vs numéro de version de bloc

Les transactions et les blocs portent tous deux un champ de version de quatre octets, et ils n'ont rien à voir l'un avec l'autre.

La version de bloc suit les mises à niveau du consensus. Les blocs de version 2 sont devenus obligatoires au bloc 227 931 en mars 2013 lorsque le BIP34 a exigé la hauteur du bloc dans l'entrée de la coinbase, la version 3 a imposé un encodage strict des signatures DER au titre du BIP66, et la version 4 est venue avec le déploiement de CHECKLOCKTIMEVERIFY. À partir de 2015, le champ a été réaffecté comme ensemble de bits de signalisation au titre du BIP9, afin que les mineurs puissent voter une soft fork en modifiant un seul bit. Un numéro de version de transaction ne fait rien de tout cela. Il ne signale jamais, il ne s'incrémente pas à chaque mise à niveau, et il s'applique à une transaction plutôt qu'à l'ensemble des règles du réseau.