Bloc de version 2

Les numéros de version de bloc avaient autrefois un sens simple : 1 était le format d'origine, 2 a ajouté une règle, et chaque nouveau numéro rendait l'ancien format impossible à miner. La version 2 est arrivée avec le BIP34 et Bitcoin Core l'applique à partir du bloc 227 931. Rien de ce que vous faites comme acheteur n'en dépend, mais chaque explorateur l'affiche, et cela explique pourquoi les scripts coinbase commencent par un nombre.

Comment cela fonctionne

Statut : le champ de version a cessé d'être un compteur en 2016, lorsque le BIP9 a redéfini ses bits supérieurs comme un champ de bits de signalisation, de sorte qu'un bloc moderne affiche une valeur telle que 0x20000000 plutôt que 2, 3 ou 4. La règle du BIP34 introduite par la version 2 est permanente et toujours vérifiée sur chaque bloc.

Les blocs de version 2 existent pour résoudre un problème d'identité en double. Une transaction coinbase n'a aucune entrée pour la rendre unique, donc deux mineurs qui utilisaient par hasard le même script de sortie et les mêmes octets de coinbase arbitraires pouvaient produire des transactions identiques octet par octet avec le même identifiant de transaction. Ce n'est pas hypothétique : les blocs 91 842 et 91 880 contenaient chacun une transaction coinbase identique à une transaction d'un bloc antérieur, et la copie plus récente écrasait l'entrée précédente dans l'ensemble des sorties non dépensées, détruisant des bitcoins dépensables. Le BIP30 a interdit les doublons purement et simplement à titre provisoire, et le BIP34 a supprimé la possibilité à la source.

Le mécanisme est modeste. Un bloc de version 2 doit commencer son script coinbase par la hauteur du bloc lui-même, écrite comme un nombre de script encodé de façon minimale. Comme deux blocs ne partagent jamais une hauteur, deux transactions coinbase ne peuvent plus jamais entrer en collision. Le déploiement a utilisé un seuil plutôt qu'une date fixe : une fois qu'une supermajorité des blocs récents portait la version 2, les blocs de version 1 sont devenus invalides, et le réseau a franchi ce point en mars 2013.

Le même schéma s'est reproduit deux fois. Les blocs de version 3 ont rendu obligatoire l'encodage strict des signatures DER au bloc 363 725, et les blocs de version 4 ont apporté OP_CHECKLOCKTIMEVERIFY au bloc 388 381. Ensuite la séquence s'est arrêtée, parce que traiter un champ de 32 bits comme un compteur gaspillait 31 bits que le BIP9 a transformés en signaux de mise à niveau parallèles.

Où le voir

La version apparaît sur la page d'un bloc de n'importe quel explorateur et dans l'appel RPC getblock, à la fois comme version et comme versionHex. Regardez un bloc de 2011 et vous voyez 1 ; regardez-en un du milieu de 2013 et vous voyez 2 ; regardez-en un d'aujourd'hui et vous voyez un champ de bits.

La hauteur du BIP34 est plus facile à repérer que la version elle-même. Décodez n'importe quel script coinbase récent et les premiers octets sont la hauteur, généralement suivis du texte d'identification d'une pool et de l'espace de nonce supplémentaire que parcourt le matériel de minage. Les explorateurs affichent souvent cette fin en ASCII, ce qui permet au coinbase d'un bloc de révéler quelle pool l'a miné.

Bloc de version 2 vs transaction de version 2

Un bloc de version 2 et une transaction de version 2 partagent un numéro et rien d'autre. La version de transaction 2 vient du BIP68 et active les verrous temporels relatifs, permettant à une entrée d'exiger que sa sortie parente ait un âge donné avant de pouvoir être dépensée. Lightning en dépend pour les délais d'expiration des canaux. La version de bloc 2 vient du BIP34 et concerne l'unicité du coinbase. Objet différent, BIP différent, année différente, et aucun rapport au-delà de la coïncidence que les deux compteurs atteignent 2.