Soft Fork

Marquons d'un V(old) tous les blocs acceptés par les règles avant la mise à jour. Le changement n'est un soft fork que si V(new) se trouve à l'intérieur de V(old) : le nouveau nœud rejettera la classe de blocs suivante, mais un bloc conforme aux nouvelles règles passera également les anciennes vérifications. Le nom parle de la compatibilité des règles de validité, et non de l'ampleur, de la sécurité ou de la compatibilité sociale du changement. Augmenter la limite visible pour un ancien nœud ou autoriser une dépense auparavant invalide élargit le pool et nécessite généralement un hard fork. [Guide du développeur Bitcoin – Modifications des règles de consensus] [Bitcoin Optech – Activation du soft fork]

Un ancien nœud complet peut continuer à suivre la chaîne car les mineurs mis à jour créent régulièrement des blocs qu'il reconnaît. Mais cela ne vérifie pas la condition ajoutée. Si une branche avec plus de travail enfreint la nouvelle règle, l'ancien nœud peut l'accepter, tandis que celui mis à jour la rejette. Ceux qui ont besoin d'une nouvelle garantie doivent mettre à jour leur propre logiciel de validation ; la capacité d'un portefeuille à accepter les paiements, la compatibilité des formats et la validation par consensus complet sont des choses différentes. [Guide du développeur Bitcoin — Modifications des règles de consensus] [BIP 341 — Déploiement Taproot]

Bitcoin a créé des sous-ensembles en utilisant plusieurs techniques. BIP66 a interdit les signatures DER non strictes acceptées par les anciennes règles. BIP65 et BIP112 ont ajouté des conditions aux opcodes NOP que l'ancien interprète considérait comme une réussite sans rien faire. SegWit et Taproot ont donné un sens aux versions réservées du programme témoin, que l'ancien nœud considère comme étant accessible à tous. Dans le même temps, la conception doit empêcher le contournement du nouveau contrôle ; SegWit a donc validé les données des témoins via Coinbase et conservé les anciennes règles de bloc de base. [BIP 66 — Signatures DER strictes] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 141 — Témoin séparé] [BIP 341 — Déploiement de racine pivotante]

Le code peut contenir une règle inactive bien avant qu'elle ne prenne effet sur le réseau principal. BIP et l'implémentation vérifiée ne sont pas des déploiements, les paramètres de déploiement ne sont pas verrouillés, le verrouillage planifie uniquement l'application future, et seul l'état ACTIF signifie vérifier le bloc donné. Chaque nœud calcule l'état à partir des ancêtres de sa propre branche. Une réorganisation à la frontière peut la recalculer et des logiciels avec des paramètres différents peuvent commencer à appliquer des règles incompatibles. [BIP 9 — Bits de version avec délai d'attente et délai] [Bitcoin Core — versionbits.cpp]

BIP9 attribue un nom, une version binaire, une heure de début et un délai d'expiration au déploiement. La variante originale du réseau principal évalue les périodes après 2 016 blocs : après au moins 1 916 blocs de signalisation, soit 95 %, elle passe de STARTED à LOCKED_IN, attend une période et est ensuite ACTIVE ; sinon, cela pourrait finir par échouer. La séquence complète est DEFINED, STARTED, LOCKED_IN, ACTIVE et FAILED. L'état d'un bloc dépend de ses ancêtres, pas de sa propre nVersion, et la signalisation après le verrouillage ne change plus le résultat. [BIP 9 — Bits de version avec timeout et délai]

Les bits de version indiquent que le mineur est prêt et coordonnent la transition ; ils n’accordent pas aux mineurs la propriété permanente du consensus. BIP8 utilise des hauteurs et, avec lockinontimeout, peut forcer la signalisation dans la dernière fenêtre. BIP148, d'autre part, a ordonné aux nœuds participants de rejeter les blocs de signalisation non SegWit ; BIP91 a abaissé le seuil d'exploitation minière pour se coordonner avec cette pression. L'activation obligatoire peut diviser la chaîne si les nœuds, le taux de hachage et l'adoption économique divergent, de sorte que même la méthode d'activation constitue un compromis de sécurité. [BIP 8 — Version bits avec verrouillage par hauteur] [BIP 148 — Activation obligatoire de SegWit] [BIP 91 — Seuil réduit SegWit MASF] [Bitcoin Optech — Activation Soft fork]

P2SH sous BIP16 a été activé en 2012 par la signalisation Coinbase et la limite de temps. BIP34 a utilisé la version bloc et le seuil pour la hauteur obligatoire dans coinbase. La même procédure de nombre entier exécutait un DER strict dans BIP66 et CHECKLOCKTIMEVERIFY dans BIP65, mais consommait les valeurs de version et ne pouvait pas effectuer de déploiements simultanés. BIP9 a donc introduit des bits indépendants. BIP68, BIP112 et BIP113 ont ensuite été activés ensemble en tant que temps de verrouillage relatif et CSV à la hauteur 419 328 en 2016. [BIP 16 — Pay to Script Hash] [BIP 34 — Block v2, height in coinbase] [BIP 65 — CHECKLOCKTIMEVERIFY] [BIP 66 — Signatures DER strictes] [BIP 112 — CHECKSEQUENCEVERIFY]

SegWit a été activé sur 481 824 en août 2017. Un ancien nœud voit une transaction sans données de témoin et considère le témoin v0 comme étant accessible à tous ; Témoin de vérification mis à jour, nouveau résumé de signature et règles anti-malléabilité. L'engagement de Merkle à témoigner des données dans la sortie de Coinbase empêche un mineur de modifier ou d'omettre des données sans détection. La facturation au poids a augmenté la capacité effective sans que le bloc sous-jacent visible par l'ancien nœud ne dépasse l'ancienne limite d'un mégaoctet. [BIP 141 — Témoin séparé]

Les programmes témoins BIP341 et BIP342 version 1 dépensent le chemin de clé et le chemin de script avec les signatures Schnorr et Tapscript. L'ancien nœud traite à nouveau le programme réservé comme si tout le monde pouvait le dépenser : le sous-ensemble est préservé, la validation complète ne l'est pas. Le réseau principal a utilisé un BIP9 Speedy Trial modifié avec un seuil de 1 815 blocs sur 2 016, soit 90 %, et une hauteur d'activation minimale de 709 632. Taproot y a été activé le 14 novembre 2021 ; Les règles de Taproot et comment les activer sont deux questions d'audit distinctes. [BIP 341 — Déploiement Taproot] [BIP 342 — Tapscript] [Notes de version Bitcoin Core 0.21.1 — Déploiement Taproot]

Lorsque BIP66 a été activé en juillet 2015, certains mineurs ont signalé la nouvelle version mais n'ont pas suffisamment validé le bloc parent sur lequel ils exploitaient. Ils ont étendu le bloc invalide et créé une branche invalide de six blocs le 4 juillet ; un autre incident plus court a suivi le lendemain. Les nœuds de validation mis à jour ont rejeté les deux branches. Le numéro de version ou le bit constitue une affirmation du mineur, et non une preuve qu'il a lui-même vérifié le modèle, les parents et les transactions. [BIP 66 — Signatures DER strictes] [Bitcoin.org — Alerte de fourche de chaîne BIP66 de juillet 2015]

Dans l'état ACTIF, les nœuds mis à jour rejettent le bloc incriminé quel que soit le partage du taux de hachage ; La question de savoir si une division permanente se produit dépend du travail des succursales et de leur utilisation économique. La simple suppression de la restriction réactiverait les blocs invalides d'aujourd'hui et constitue donc un hard fork ; les paramètres ou le code peuvent être remplacés par une version coordonnée avant l'activation. L'opérateur vérifie sa propre version, getdeploymentinfo ou getblockchaininfo, les paramètres exacts, la hauteur d'activation et les journaux. Ni le graphe de signalisation ni l'étiquette de l'explorateur ne peuvent remplacer la validation locale. [Guide du développeur Bitcoin — Modifications des règles de consensus] [Bitcoin Core — versionbits.cpp] [Notes de version Bitcoin Core 0.21.1 — Déploiement Taproot]