Hard Fork

Notons V(ancien) l’ensemble des blocs acceptés par les règles d’origine. Il y a Hard Fork lorsque le nouveau logiciel accepte au moins un bloc extérieur à cet ensemble, de sorte que V(nouveau) n’est pas un sous-ensemble de V(ancien). Il s’agit souvent d’élargir l’ensemble des blocs valides, mais le critère décisif est la compatibilité : si un bloc valide pour un nouveau nœud peut être invalide pour un ancien, l’ancien validateur ne peut pas suivre la nouvelle chaîne sans modifier ses règles. [Bitcoin Developer Guide — Consensus rule changes]

Un ancien Full Node ne connaît ni ne reconnaît la nouvelle règle. Dès que les mineurs ayant adopté la mise à jour produisent un bloc qui dépasse une ancienne limite ou utilise une construction nouvellement autorisée, l’ancien nœud s’arrête au dernier bloc qu’il considère comme valide et rejette la branche qui lui succède. Il n’est pas mis en minorité par un vote ; il exécute de manière déterministe un autre programme de consensus. [Bitcoin Developer Guide — Consensus rule changes]

Une date fixe, une hauteur de bloc ou la signalisation des mineurs peuvent coordonner les participants qui ont adopté la mise à jour, mais ne peuvent pas modifier le logiciel d’un nœud qui ne l’a pas adoptée. Si chacun des deux ensembles de règles conserve des participants économiquement importants, les deux chaînes peuvent continuer. Le plan d’activation d’un Hard Fork est donc un plan de migration comportant un risque de scission. [Bitcoin Developer Guide — Consensus rule changes]

Au point de scission, les deux branches héritent du même historique antérieur des UTXO. Elles peuvent ensuite confirmer des transactions différentes, appliquer des limites différentes et accumuler des quantités différentes de chainwork. Si les deux survivent, un détenteur possède généralement un droit correspondant sur les coins des deux chaînes, limité par les règles ultérieures, la protection contre le replay et la prise en charge par les portefeuilles. Il ne s’agit plus d’une seule écriture comptable. [BCHN Technical Bulletin — shared history and 2017 split]

Proof of Work départage les branches seulement après que le nœud a reconnu les blocs comme valides. Un ancien nœud ne compare jamais le chainwork d’une branche contenant un bloc invalide selon ses anciennes règles à celui de sa propre chaîne ; il écarte d’abord cette branche. L’affirmation « la chaîne avec le hashrate le plus élevé gagne » est donc incomplète si les règles de validation ne sont pas précisées. [Bitcoin Developer Guide — Consensus rule changes]

Un même format de signature et de transaction peut rendre une transaction signée valide sur les deux réseaux après leur scission. C’est le risque de replay. Un fork peut ajouter une protection, un sighash différent ou un autre format d’adresse, mais il s’agit de mesures distinctes. L’utilisateur doit distinguer les réseaux, les soldes, les adresses dérivées et les règles des plateformes d’échange concernant le crédit des dépôts et les retraits. [Bitcoin Cash upgrade specification — 2017 hard fork]

Bitcoin Cash s’est séparé de Bitcoin à la hauteur de bloc 478 559, le 1er août 2017. Il a adopté des règles permettant des blocs plus grands que ceux acceptés à l’époque par les nœuds Bitcoin et a créé sa propre chaîne qui s’est poursuivie indépendamment. Les nœuds Bitcoin ont rejeté les blocs valides uniquement selon les règles de BCH, tandis que les nœuds BCH ont suivi leur propre historique valide. C’est un exemple de Hard Fork qui n’a pas remplacé Bitcoin sur place, mais a créé un réseau distinct. [Bitcoin Cash upgrade specification — 2017 hard fork] [BCHN Technical Bulletin — shared history and 2017 split]

Toute scission incompatible n’est pas nécessairement un nouveau projet monétaire délibéré. Un bug logiciel peut provoquer un désaccord temporaire entre les implémentations, et une version d’urgence peut ramener les participants à un seul ensemble de règles. La scission de Bitcoin en mars 2013 résultait de différences de comportement entre les versions concernant la base de données et ses limites. Elle a été résolue par le retour coordonné des mineurs vers la branche acceptée par les anciens nœuds de version 0.7 ; elle ne se confond pas avec le réseau BCH maintenu durablement. [BIP 50 — March 2013 chain fork post-mortem]

Un Soft Fork restreint l’ensemble de validité de sorte que V(nouveau) reste à l’intérieur de V(ancien). Un ancien nœud peut suivre les blocs compatibles, mais n’applique pas la nouvelle restriction. Un Hard Fork ne possède pas cette compatibilité à sens unique : un nouveau bloc valide peut être invalide pour un ancien nœud. Même un Soft Fork peut entraîner une scission si la coordination est mauvaise ; un Hard Fork exige toutefois une migration par sa définition même. [Bitcoin Developer Guide — Consensus rule changes]

Les développeurs peuvent publier du code, les mineurs réaffecter leur hashrate, les entreprises choisir un ticker et des règles de dépôt, et les utilisateurs choisir leur logiciel. Aucune de ces actions ne réécrit à elle seule le consensus des autres. Une scission durable peut persister si suffisamment de participants indépendants maintiennent volontairement les deux ensembles de règles et leur accordent de la valeur ; toute modification incompatible ne crée pas nécessairement deux réseaux durablement actifs. Qualifier une branche de « mise à jour » relève d’une convention sociale, et non d’une règle de consensus. [Bitcoin Developer Guide — Consensus rule changes]

L’opérateur doit vérifier l’identification du réseau, la version précise du logiciel, les paramètres de consensus, les pairs, la tête de chaîne, le hash du bloc au point du fork ainsi que les notes de version ou les checkpoints correspondants. Pour des fonds importants, il est judicieux de séparer les portefeuilles et les procédures avant de dépenser les coins issus d’un fork. Un explorateur ou un ticker peut aider, mais ne remplace pas le propre nœud de validation de l’opérateur. [Bitcoin Core v29.0: getblockchaininfo]