Il ne s’agissait pas d’un désaccord sur une nouvelle règle, mais d’une dépendance cachée de la validation à l’implémentation de la base de données : LevelDB traitait un bloc comptant un nombre inhabituel d’entrées, tandis que les versions précédentes épuisaient le nombre de verrous Berkeley DB par défaut ; les mineurs coordonnèrent donc un retour à la branche compatible et la version 0.8.1 prépara ensuite une transition contrôlée.
Le 11 mars 2013, un nœud exécutant Bitcoin 0.8 mina le bloc 225 430. La nouvelle version l’accepta, tandis qu’une partie des nœuds en 0.7.2 et antérieurs le refusa ; une branche contenant ce bloc et une autre sans lui poussèrent donc depuis le même parent. La différence ne tenait pas au hash ni au proof of work, mais au fait que le logiciel local jugeait ou non le bloc valide. [2]
Le déclencheur n’était pas simplement la taille du bloc en octets. Le bloc contenait un nombre d’entrées de transaction encore jamais vu et les anciens nœuds épuisèrent le nombre de verrous Berkeley DB par défaut lors de leur écriture. Le nombre requis dépendait aussi de l’agencement des pages de la base de données de chaque nœud ; un bloc plus petit mais autrement valide pouvait ainsi échouer là où des blocs de test de taille maximale avaient réussi. [1]
Bitcoin 0.8 déplaça les index de blocs et de transactions de Berkeley DB vers LevelDB, qui n’avait pas la même limite de verrous. Environ 60 % du hashrate construisait d’abord sur la branche 0.8, mais les anciens nœuds ne comptaient pas son travail parce qu’ils rejetaient son bloc initial. La règle de la chaîne la plus lourde ne choisit qu’entre des historiques préalablement validés par le nœud ; elle ne pouvait donc pas résoudre seule ce désaccord. [1]
Pieter Wuille publia l’alerte d’urgence et recommanda aux commerçants de suspendre le traitement des paiements. Après discussion entre développeurs et opérateurs, BTCGuild, dirigé par Michael Marsee dit Eleuthria, et Slush Pool de Marek Palatinus revinrent à Bitcoin 0.7. Le but n’était pas de déclarer définitivement fausse la branche techniquement plus récente, mais de concentrer rapidement le travail sur un historique que les deux versions largement déployées savaient valider. [3]
Lorsque la branche compatible prit l’avantage en travail cumulé, les nœuds 0.8 se réorganisèrent vers elle et les blocs minés uniquement sur la branche 0.8 initiale devinrent stale. BIP 50 relève au moins un double spend important durant la scission ; le post-mortem indique qu’il s’agissait d’une expérience et non d’un vol intentionnel. L’épisode montra néanmoins pourquoi plateformes et commerçants suspendent les dépôts et attendent davantage de confirmations lorsque la pointe de chaîne est incertaine. [1]
Bitcoin Core 0.8.1 fut publié le 18 mars 2013. Il introduisit une règle temporaire d’acceptation des blocs, appliquée du 21 mars au 15 mai, empêchant d’accepter des blocs que les anciens pairs ne pouvaient traiter, et ajouta un checkpoint intégré au bloc 225 430. Le post-mortem précise aussi une estimation de 10 000 verrous, une limite de minage de 500 000 octets et des backports dotés d’une limite de 537 000 verrous Berkeley DB. [4]
La compatibilité temporaire n’était pas l’état final. Les opérateurs d’anciens nœuds avaient jusqu’au 15 mai pour passer à 0.8.1, adopter un backport à jour ou relever explicitement la limite de verrous ; les mineurs ne devaient pas l’augmenter avant la date coordonnée, au risque de recréer un bloc rejeté par le reste du réseau. Le 16 août 2013, le réseau accepta le bloc 252 451 et laissa définitivement derrière lui les nœuds non corrigés. [5]
L’incident montra que le consensus dépasse la description du format de bloc. Il inclut le comportement exact du code de validation, des bibliothèques, des transactions de base de données, des chemins d’erreur et des tests aux limites. Les suites comprirent donc la génération intensive de transactions sur testnet, de meilleures alertes pour les services, la surveillance des longues branches latérales et une coordination plus prudente des changements ; le rétablissement rapide révéla aussi la dépendance de l’époque envers quelques développeurs joignables et grands pools. [1]
Pour une vision complète, lisez aussi Bitcoin Core, Règles de consensus, Hard Fork, Reorg, Full Node, Mining Pool. Cette entrée est également citée par Schelling Point.
01Un groupe a-t-il décidé quelle blockchain était la vraie ?+
Développeurs et grands pools ont coordonné l’urgence, sans pouvoir réécrire les nœuds à distance. BTCGuild et Slush ont changé le logiciel utilisé par leurs mineurs, tandis que les utilisateurs exécutaient des versions dotées de leurs propres règles de validation. La branche compatible ne l’a emporté qu’après avoir été acceptée par assez de nœuds et avoir accumulé davantage de travail pour les nœuds Bitcoin 0.8.
02Les deux branches étaient-elles valides en même temps ?+
Cela dépendait de la version qui validait. Bitcoin 0.8 jugeait valides le bloc 225 430 et sa branche, tandis que certains anciens nœuds rejetaient le bloc à cause de la limite Berkeley DB et ne connaissaient que l’autre branche. Des réponses différentes aux mêmes données constituent précisément une défaillance du consensus ; l’historique actif actuel poursuit la branche compatible choisie de façon coordonnée.