Soft Fork

Imaginons Anna et Pavel, qui vérifient chacun Bitcoin sur leur propre ordinateur. Anna a mis son logiciel à jour, Pavel pas encore. Une modification semblable à BIP66 arrive : les signatures numériques, qui prouvent l'autorisation de dépenser certains bitcoins, doivent respecter un format plus précisément défini. Certains encodages auparavant acceptés deviennent interdits. Un paiement doté d'une signature valide au format désormais exigé passe ce contrôle chez tous les deux. Mais si la signature emploie un encodage autrefois permis et maintenant interdit, Anna la rejette alors que Pavel peut encore l'accepter. On suppose ici que le paiement respecte toutes les autres règles. Voilà le principe du Soft Fork : les nouvelles règles interdisent des cas supplémentaires sans autoriser ce que les anciennes interdisaient. Tant que les mineurs produisent des blocs conformes aux règles durcies, Anna et Pavel peuvent tous deux suivre la chaîne. Pavel ne vérifie cependant pas lui-même la condition ajoutée. Un Soft Fork permet donc de modifier Bitcoin sans mettre tous les nœuds à jour simultanément. Cela ne donne pas à l'ancien logiciel les mêmes contrôles qu'au nouveau et ne crée pas, à lui seul, une seconde monnaie. [1] [6]

Un Full Node est un ordinateur qui vérifie de façon indépendante les règles de Bitcoin. Pour choisir entre des branches valides, il compare le travail cumulé démontré par le minage, pas les voix de leurs partisans. L'ancien full node peut suivre la chaîne puisque les mineurs mis à jour produisent normalement des blocs qu'il reconnaît. Il ne vérifie pourtant pas la condition ajoutée : il peut accepter une branche ayant plus de travail mais violant la nouvelle règle, rejetée par les nœuds à jour. Pour vérifier soi-même la nouvelle condition, il faut mettre à jour son logiciel de vérification. Pouvoir recevoir un paiement ou reconnaître un format d’adresse ne signifie pas vérifier toutes les règles du réseau. [1] [12]

Un BIP est une proposition technique numérotée. Sa publication ne change pas le réseau : il faut développer et vérifier un logiciel, puis ses utilisateurs décident de l’adopter ou non. Mainnet désigne le réseau principal de Bitcoin, où circulent de vrais bitcoins. L’activation détermine à partir de quand les nœuds mis à jour y exigent le respect de la nouvelle règle. La présence du code dans un logiciel ne signifie donc pas qu’il sert déjà à vérifier les blocs. Dans les procédures décrites ici, le lock-in signifie que la condition d’une activation ultérieure est remplie ; la règle n’est pas nécessairement appliquée à ce stade. Le nœud la vérifie seulement à l’état ACTIVE. Il calcule cet état à partir des blocs précédents de sa propre branche. Si une réorganisation modifie cet historique près de la limite d’activation, le résultat peut changer. Deux logiciels ayant des paramètres d’activation différents peuvent ainsi accepter des blocs différents au même moment. [2] [15]

Le mineur construit son bloc à la suite d'un bloc précédent, appelé bloc parent. Sans le vérifier, il risque de travailler en vain sur une branche que les autres nœuds refuseront. En juillet 2015, des mineurs signalaient BIP66 sans valider correctement leur parent. Ils ont prolongé un bloc invalide, créant une branche invalide de six blocs le 4 juillet, puis une autre plus courte le lendemain. Les nœuds à jour les ont rejetées. Un bit ou numéro de version est une déclaration du mineur, pas la preuve qu’il a vérifié le bloc préparé, son prédécesseur et les transactions qu’il contient. [6] [14]

Pour savoir quelles règles votre nœud applique réellement, commencez par sa version et les informations qu’il fournit lui-même. Selon la version, getdeploymentinfo et getblockchaininfo renseignent sur les changements déployés et sur la chaîne. Avec la documentation de cette version, la hauteur d’activation et les journaux, ils permettent de distinguer une règle préparée d’une règle déjà active. Un explorateur de blocs sur le Web montre le point de vue d’un autre service ; il ne prouve pas ce que votre ordinateur vérifie. Le hashrate mesure la puissance de calcul du minage. Il ne donne pas aux mineurs le droit de contourner les règles de votre nœud : à l’état ACTIVE, un nœud mis à jour rejette un bloc qui enfreint la nouvelle condition, même si la majorité de la puissance de calcul le soutient. La persistance d’une séparation dépend aussi du travail accumulé par les branches et de leur utilisation économique. Supprimer simplement une restriction active autoriserait de nouveau des blocs actuellement invalides : ce serait un Hard Fork. Avant l’activation, une version logicielle coordonnée peut modifier les paramètres, mais ce changement ne s’installe pas de lui-même sur les nœuds des autres. [1] [15] [16]

V(ancien) contient tous les blocs acceptés avant la mise à jour. Il n'y a Soft Fork que si V(nouveau) y est inclus : le nouveau nœud rejette davantage de cas et tout bloc conforme aux nouvelles règles passe encore les anciennes. Le terme décrit la compatibilité des règles, non l'importance, la sûreté ou l'accord social. Augmenter une limite visible par l'ancien nœud ou autoriser une dépense auparavant invalide élargit l'ensemble et exige normalement un Hard Fork. [1] [17]

Des règles plus strictes peuvent aussi apporter une nouvelle fonction. BIP66 a précisé DER, le format d'encodage des signatures. BIP65 et BIP112 ont ajouté des conditions temporelles de dépense à certaines instructions NOP, qui n'imposaient auparavant aucune condition. SegWit a introduit les programmes witness et les données de validation appelées witness, notamment les signatures. Taproot a ensuite utilisé leur version réservée 1. Les anciens nœuds ne vérifient pas les nouvelles conditions correspondantes. Anyone-can-spend décrit cette vision limitée, pas un moyen de contourner les nœuds à jour pour dépenser les fonds d'autrui. SegWit lie également les données witness au bloc par un engagement cryptographique, le witness commitment. Celui-ci figure dans la transaction coinbase, la première transaction contenant la récompense du mineur, et préserve la compatibilité avec les anciennes règles du bloc de base. [6] [5] [7] [8] [12]

Un bit vaut 0 ou 1. Dans nVersion, le champ de version de l’en-tête du bloc, certains bits peuvent signaler qu’un mineur est prêt. BIP9 attribue à chaque déploiement un nom, un bit précis, une date de début et une échéance. La procédure initiale du mainnet examine des périodes de 2016 blocs. Si au moins 1916 blocs signalent leur soutien pendant STARTED, soit 95 %, la période suivante passe à LOCKED_IN. Une période d’attente supplémentaire précède ensuite ACTIVE. Si la condition n’est pas remplie avant l’échéance, la procédure peut se terminer en FAILED. L’état initial, avant le démarrage, s’appelle DEFINED. Chaque nœud calcule cette succession d’états à partir des blocs précédents. Le nVersion d’un bloc ne décide donc pas à lui seul si la nouvelle règle s’applique à ce bloc. Les signaux servent à coordonner la transition, pas à voter sur la validité de chaque bloc. Une fois le lock-in atteint, les signaux ultérieurs ne changent plus l’issue de cette procédure. [2]

Versionbits permet aux mineurs de signaler leur préparation, pas de réécrire les règles des autres nœuds. BIP8 utilise les hauteurs de bloc plutôt que des limites temporelles. Si lockinontimeout vaut true et que le déploiement n’a pas encore atteint le lock-in, la dernière période peut passer à MUST_SIGNAL, avec signalisation obligatoire. BIP148 imposait aux nœuds participants de rejeter les blocs qui ne signalaient pas SegWit ; BIP91 utilisait un seuil de signalisation minière plus bas pour coordonner cette transition. Si l’application des règles, le hashrate et l’acceptation économique divergent, la chaîne peut se scinder. Le choix de l’activation comporte donc des compromis de sécurité. [11] [9] [10] [17]

P2SH (BIP16) permet d’envoyer des fonds vers l’empreinte d’un script, c’est-à-dire un programme définissant les conditions de leur dépense future. Lors de son introduction en 2012, les signaux inscrits dans les transactions coinbase ont aidé à évaluer la préparation des mineurs. Mais les nouveaux contrôles ont commencé à s’appliquer à partir d’une limite fixée pour l’horodatage des blocs ; les signaux ne remplaçaient pas la vérification. La coinbase est la première transaction du bloc et contient la rémunération du mineur. Les changements suivants ont utilisé la version du bloc et des seuils de signalisation. BIP34 a imposé l’inscription dans la coinbase de la hauteur du bloc, sa position dans la chaîne. BIP66 a renforcé le format DER des signatures, tandis que BIP65 a introduit CHECKLOCKTIMEVERIFY pour imposer une heure ou une hauteur minimale de dépense. Augmenter successivement le numéro de version compliquait le déploiement parallèle de changements indépendants. BIP9 a donc introduit des bits distincts. En 2016, BIP68, BIP112 et BIP113 ont été activés ensemble à la hauteur 419328, mais chacun traite un aspect différent des conditions temporelles. BIP68 introduit une attente relative à la confirmation de la sortie dépensée. BIP112 permet de l’exiger dans un script avec CHECKSEQUENCEVERIFY, ou CSV. BIP113 change plutôt la référence temporelle d’un verrou absolu : au lieu de l’horodatage du bloc évalué, il utilise Median Time Past, la médiane des horodatages des 11 blocs précédents. Leur activation commune ne signifie donc pas qu’ils introduisent tous le même verrou relatif. [3] [4] [5] [6] [7] [18] [19] [20]

SegWit a été activé à la hauteur 481824 en août 2017. Il a séparé les données de vérification witness, dont les signatures, de la partie de la transaction servant au calcul de son identifiant txid. Pourquoi est-ce utile ? Avec l’ancien encodage, quelqu’un pouvait modifier la représentation d’une signature et donc l’identifiant de la transaction sans changer le destinataire ni le montant. C’est ce qu’on appelle la malléabilité. Modifier les seules données witness ne change pas le txid ; cette solution ne corrige toutefois pas les entrées qui utilisent encore l’ancien format. Un ancien nœud voit la transaction sans les données witness et considère un programme witness v0 comme anyone-can-spend. Un nœud mis à jour vérifie en plus le witness et le digest de signature, l’empreinte des données signées. Le witness commitment inscrit dans une sortie coinbase relie cryptographiquement les données witness au bloc, ce qui permet à une vérification complète de détecter leur modification ou leur omission. Le weight, la pondération des données dans le calcul de la capacité du bloc, a accru la capacité effective. Le bloc de base visible par les anciens nœuds reste dans la limite initiale d’un mégaoctet. [8]

Key-path permet de dépenser avec une signature correspondant à la clé de sortie ; script-path impose les conditions d'un script révélé. Schnorr est un procédé de signature, Tapscript le langage de ces scripts. BIP341 et BIP342 définissent les dépenses par clé et par script, avec signatures Schnorr et Tapscript, pour les sorties SegWit natives dont le programme witness de version 1 mesure 32 octets. Les anciens nœuds le voient comme anyone-can-spend : compatibilité, mais pas validation complète. Speedy Trial a utilisé une version modifiée de BIP9, avec un seuil de 1815/2016 (90 %) et une hauteur minimale de 709632. Taproot s'y est activé le 14 novembre 2021. Les règles et leur mécanisme d'activation s'auditent séparément. [12] [13] [16]