Voilà ma traduction [1] d’un article publié le 4 décembre sur bitcoinmagazine.com. Pete Rizzo et Aaron Van Wirdum y retracent l’histoire passionnante et assez méconnue du premier conflit de gouvernance de l’Histoire de Bitcoin. L‘épisode commence fin de l’année 2011. La première mise à jour majeure du protocole Bitcoin depuis le départ de Satoshi Nakamoto est alors sur le point d’aboutir…
« Repoussez la date de deux mois. OP_EVAL n’est tout simplement pas encore prêt. » Par cette unique sentence Russell O’Connor, bloqua, juste avant sa mise en œuvre, une importante mise à jour de Bitcoin – la première depuis le départ de Satoshi Nakamoto – qui avait coûté des mois de travail à Gavin Andresen.
Comme l’a révélé O’Connor, la nouvelle commande proposée – annoncée par Andresen comme « la route la plus rapide » vers des portefeuilles Bitcoin plus sécurisés – pouvait être exploitée pour créer des transactions créant des boucles de calcul infinies. En bref, OP_EVAL pourrait être détourné pour faire planter les nœuds Bitcoin, et donc le réseau Bitcoin : « Il ne m’a fallu que 70 minutes de recherche pour trouver ce bogue », écrivait alors O’Connor, condamnant un processus qui avait failli permettre l’intégration de lignes de code malicieuses dans le logiciel Bitcoin. « Vous devez arrêter ce que vous êtes en train de faire et essayer de comprendre Bitcoin ».
C’était le premier revers sérieux pour Andresen, le nouveau chef de file du projet, qui n’a pas tardé à protester. Selon lui, abandonner OP_EVAL ne réduirait pas seulement des mois de codage et de révision à néant, cela priverait les utilisateurs d’un outil les protégeant contre les chevaux de Troie et les virus qui pillaient alors leurs portefeuilles numériques.
Au cœur de la proposition OP_EVAL, des portefeuilles multi-signatures qui permettraient aux utilisateurs de récupérer leurs bitcoins, même lorsque les sauvegardes étaient perdues ; des services pouvaient être conçus pour envoyer des alertes de type bancaire, dissuadant la fraude et le vol ; et mieux encore, tout cela pourrait être réalisé dans des transactions qui ressembleraient à ce que les utilisateurs connaissaient.
Mais l’avertissement d’O’Connor fut suffisant pour convaincre ceux que le rythme soutenu du développement inquiétait :« Je voudrais rappeler à tout le monde que nous sommes en train de jouer avec plus de 20 millions de dollars », écrivait alors le développeur Alan Reiner. « Il y a plus qu’un simple logiciel en jeu – tout ce que nous faisons doit être aussi solide que le diamant. »
L’échec d’OP_EVAL aurait des implications importantes. Nakamoto avait lancé la première monnaie numérique décentralisée au monde, mais sa promesse était encore loin d’être tenue. À la fin de 2011, peu de gens comprenaient son code, et moins encore possédaient les compétences et la familiarité nécessaires pour le modifier en toute sécurité.
Comment ces développeurs devraient-ils s’organiser ? Quelles responsabilités avaient-ils envers les utilisateurs ? Et comment décider de la voie à suivre alors qu’on ne savait pas très bien qui devrait avoir le dernier mot ? Toutes ces questions occuperaient bientôt le devant de la scène dans la première grande bataille du logiciel Bitcoin.
Une succession peu orthodoxe
Les projets gratuits et open source sont le plus souvent menés par leurs fondateurs qui doivent s’harmoniser avec tous les contributeurs dont dépend leur travail. Mais quand des conflits sur la direction à suivre surgissent, ils ont une légitimité naturelle pour décider du chemin que leur création doit suivre.
Bitcoin, au début, ne faisait pas exception. Pendant les deux premières années de son existence, Nakamoto a joué le rôle de développeur principal et de dictateur bienveillant. En tant que leader incontesté, il a promulgué jusqu’à huit changements de protocole sans s’embarrasser de longs discours [1] et cela jusqu’à ce qu’il s’éloigne progressivement du projet.
À la fin de 2010, Nakamoto effacera son pseudonyme du site Web Bitcoin.org, laissant le développeur « graphique 3D » Gavin Andresen revendiquer le rôle de « chef de file de fait » du projet [2]. Les mots choisis par Andresen pour désigner son rôle étaient appropriés, car les circonstances entourant cette transition étaient inhabituelles : un bref message public, un transfert privé des droits [sur SourceForge] et d’une clé permettant d’envoyer un message d’alerte au système.
Pourtant, à l’époque, cela n’a pas posé de difficultés au groupe encore réduit (mais croissant) des codeurs de Bitcoin. La plupart étaient trop occupés par des correctifs critiques et Andresen, époux d’un professeur titulaire, avait le temps et l’enthousiasme pour diriger les travaux [3]. Il y avait de nombreux besoins urgents – une synchronisation plus rapide, de meilleurs tests – mais « les témoignages de plus en plus fréquents de wallets pillés » et la « mauvaise image publique » que donnaient ces vols étaient rapidement devenus une préoccupation majeure.
Ce fut, pendant un certain temps, l’objectif sur lequel le nouveau groupe de contributeurs de Bitcoin semblait d’accord [4].
Première version du multisig
Heureusement une ébauche de solution avait été fournie par Nakamoto lui-même. Comme Andresen l’apprendrait, le code de Bitcoin permettait déjà aux utilisateurs de créer des transactions sécurisées qui ne pouvaient être dépensées que lorsqu’elles étaient signées avec plusieurs clés privées [5]. Avec la multisignature, ou multisig pour faire court, les clés privées pourraient être stockées sur plusieurs appareils, à des extrémités opposées du monde, ou partagées entre un utilisateur et un service de portefeuille. Voler les fonds deviendrait compliqué pour les pirates car il fallait réussir à compromettre plusieurs cibles.
Enthousiasmé par l’idée, Andresen devenait son premier champion, écrivant un plaidoyer passionné sur la liste de diffusion pour inciter les contributeurs à agir : « Ma plus grande inquiétude serait que nous disions : “Il ne faudra bien sûr que quelques jours pour nous entendre sur la façon de bien faire les choses”, et que dans six mois, il n’y ait toujours pas de consensus », écrit-il [6]. « Et les wallets des utilisateurs [continueront] à être perdus ou pillés. »
Cette chemin n’était pas sans embûches. Tel qu’il avait été pensé par Nakamoto, le multisig avait des défauts importants. Le plus problématique d’entre eux était que les transactions étaient incompatibles avec le format d’adresse standard de Bitcoin et nécessitaient des adresses beaucoup plus longues. Les transactions de financement de portefeuilles multisig étaient donc plus lourdes et nécessitaient des frais plus élevés. De plus, ces frais devaient être payés non pas par la personne recevant les bitcoins sur une adresse multisig, mais par la personne qui envoyait ces bitcoins.
En raison de ces propriétés peu optimales, les transactions multisig ont été désignées comme « non standard » dans le logiciel, ce qui signifiait qu’elles ne se propageraient pas nécessairement aux nœuds du réseau. Si un nœud recevait une transaction multisig, il pouvait simplement l’ignorer. De même, il n’y avait aucune garantie que les mineurs incluraient ces transactions dans des blocs. Certes, si elles étaient incluses, les nœuds les accepteraient et ces transactions étaient finalement valides, mais dans la pratique, la désignation « non standard » a rendu presque impossible la confirmation de ces transactions.
OP_EVAL entre en scène
Pour débloquer le potentiel qu’il voyait, Andresen défendait un nouvel « code op », un type de commande que les nœuds pourraient utiliser pour décider si et quand de nouveaux types de transactions devraient être valides. Conçu pour accueillir des transactions complexes telles que le multisig, OP_EVAL s’appuyait fortement sur le hachage, l’astuce cryptographique qui brouille et compresse les données en une chaîne unique de nombres de manière déterministe, mais irréversible.
Proposé tout d’abord par le développeur anonyme ByteCoin, l’idée de base était que les utilisateurs puissent hacher des instructions détaillant les conditions de dépense des bitcoins (y compris depuis et vers des portefeuilles multisig) en incluant ce hachage dans une transaction. Les bitcoins seraient essentiellement envoyées « vers » un hash. Les conditions requises pour dépenser plus tard les fonds ne seraient révélées que lorsque les pièces ont été dépensées « depuis » le hash. L’utilisateur multisig paierait pour la taille de transaction quand il dépensait les pièces, tandis que les données supplémentaires requises seraient un moindre fardeau pour le réseau.
La proposition ayant reçu des commentaires positifs, Andresen a accéléré le processus, car il souhaitait que OP_EVAL soit déployé le plus tôt possible : « La sécurité est vraiment en haut de la liste des priorités ; j’aimerais voir des adresses Bitcoin sécurisées dans les signatures des forums d’ici un an« , écrivait-il alors [7].
Cependant tout le monde ne partageait pas le sentiment d’urgence d’Andresen. OP_EVAL était une importante mise à jour sur un système soutenant déjà des millions de dollars en valeur. De l’autre côté de l’océan, le jeune Amir Taaki suggéra alors aux développeurs de prendre le temps d’examiner la proposition : « Cela semble bon à première vue, écrivait Taaki [8], mais se précipiter n’est probablement pas une bonne idée … Bitcoin n’explosera pas demain, il n’y a donc pas de grands risques à retarder des changements aussi importants. »
Pour compliquer davantage les choses, l’ajout d’OP_EVAL au protocole poserait un défi de coordination important. Les développeurs l’avaient compris. Le problème principal c’est que sa mise en œuvre impliquait de risquer que la blockchain – l’enregistrement définitif de toutes les transactions Bitcoin, imposé par le consensus partagé et les règles logicielles – se divise en réseaux incompatibles.
Cela signifiait que dès la mise en ligne d‘OP_EVAL, chaque utilisateur devrait passer à une nouvelle version du logiciel et à une nouvelle blockchain, un processus qu’on a appelé une mise à niveau « hard fork ». Un échec de coordination, et les mineurs pourraient sans le savoir produire des blocs invalides. Pire encore, les utilisateurs pouvaient accepter sans le savoir des transactions invalides.
Un nouveau type de soft fork
Andresen réalisa cependant qu’il était possible d’apaiser ses détracteurs. Il avait découvert que OP_EVAL pouvait être déployé en redéfinissant l’un des nombreux op codes inactifs initialement inclus par Nakamoto pour des commandes futures.
À la surprise de tous, y compris d’Andresen, l’utilisation d’un op code existant serait également compatible avec les nœuds qui n’auraient pas fait la mise à jour OP_EVAL. Ces nœuds vérifieraient que le hachage correspondait aux nouvelles instructions, mais ne les appliqueraient pas, acceptant à la place les transactions par défaut.
Tant que la majorité des mineurs appliquait les nouvelles règles, la nouvelle blockchain serait considérée comme valide par les nœuds, qu’ils soient ou non mis à jour. Les nœuds à niveau accepteraient la blockchain parce que les nouvelles règles étaient appliquées, tandis que les nœuds non mis à jour accepteraient naturellement la blockchain parce qu’ils ne se soucient pas de ces nouvelles règles.
De telles mises à niveau rétro-compatibles, ou « soft forks », avaient déjà été déployées par Nakamoto, mais à mesure que la taille du réseau augmentait, les développeurs avaient commencé à s’inquiéter du grand nombre de personnes qu’il fallait impliquer dans chaque mise à jour.
Sans surprise, la nouvelle que le « hard fork » pouvait être évité a été bien accueillie par les contributeurs établis avec lesquels Andresen discutait : « Sensationnel. L’argument de Gavin selon lequel [OP_EVAL] peut être fait sans scission m’a époustouflé, s’enthousiasmait Gregory Maxwell, réagissant en temps réel à la découverte [9], Sortez le champagne. »
A la suite de cela, les développeurs ont mis au point une méthode encore plus sécurisée pour activer les soft forks. Ils ont théorisé qu’ils pourraient faire une sorte de sondage pour déterminer le niveau de soutien d’une nouvelle fonctionnalité par des mineurs, ce qui rendrait les mises à jour plus sûres. Les mineurs seraient invités à inclure un peu de données dans les blocs qu’ils ont extraits pour signaler qu’ils appliqueraient les nouvelles règles. Lorsqu’une majorité était prête, le changement pouvait être activé [10].
L’erreur fatale
Mais tout ce travail avait été annulé par les découvertes d’O’Connor.
Le résultat a été une scission en factions, certains estimant qu’OP_EVAL était inutilement retardé et d’autres soutenant que les solutions rapides proposées nuiraient à certaines propriétés essentielles du langage de script de Bitcoin.
Des développeurs tels que Luke Dashjr, Pieter Wuille et Maxwell ont suggéré des alternatives qui, comme OP_EVAL, utilisaient le concept d’envoi de fonds « vers » un hash. On a commencé parler de « pay to script hash » ou « P2SH ». Restait le défi d’intégrer cette nouveauté sans risquer une scission de la blockchain. Seuls les op-codes existants permettraient de faire en sorte que les nœuds non mis à niveau, qui ne comprennent pas les nouvelles règles, acceptent ces transactions.
C’est Andresen qui a trouvé la voie à suivre, et sa solution P2SH spécifique ne nécessiterait pas du tout un nouveau code opérationnel. L’idée d’Andresen était que Bitcoin pouvait être programmé pour reconnaître un certain format de transactions, puis interpréter ce format de manière non conventionnelle pour le valider à l’aide de nouvelles instructions. Tout nœud qui ne serait pas mis à niveau interpréterait le format non conventionnel en utilisant une logique conventionnelle. Comme avec OP_EVAL, la transaction serait toujours considérée comme valide par les nœuds non mis à niveau. Cela signifiait que P2SH pouvait être déployé comme un soft fork : tant qu’une majorité de puissance de hachage appliquait les nouvelles règles, les anciens et les nouveaux nœuds seraient d’accord sur la même blockchain.
La proposition d’Andresen paraissait satisfaisante pour la plupart. « Cela semble acceptable à première vue », avait répondu O’Connor [15]. Taaki, se référant à l’approche non conventionnelle du code, déclara quant à lui : « Cette idée est un hack…. mais j’aime ça. »
Lors d’une réunion ultérieure des développeurs, les participants ont accepté de mettre en œuvre la proposition P2SH d’Andresen. Les mineurs seraient interrogés dans la semaine précédant le 1er février, et si une majorité de puissance de hachage (55%) signalait un soutien, un client serait libéré pour activer le soft fork deux semaines plus tard.
La paix durera quelques jours.
Pourquoi ne pas utiliser des USD ?
Ce sera Dashjr qui brisera le consensus. Il avait dû quitter la réunion plus tôt et n’avait appris que plus tard que la version de P2SH d’Andresen avait été acceptée.
La nature non conventionnelle de la solution d’Andresen a irrité Dashjr, qui pensait qu’elle compliquait le protocole et entraînait des conséquences incertaines. Il a soulevé la question avec Andresen, mais ce dernier n’était pas convaincu que ses préoccupations méritaient un changement de plans [16].
Ses suggestions étant rejetées, Dashjr fera irruption sur le forum BitcoinTalk à la mi-janvier, dénonçant P2SH et accusant Andresen de vouloir porter « tout seul » ce changement [17] : « Gavin force tous ceux qui utiliseront la dernière version de Bitcoin à voter pour [P2SH], a-t-il écrit. Si vous voulez vous opposer à ce changement de protocole insensé, vous devrez modifier votre code source BitcoinD, sinon, par défaut, vous voterez EN FAVEUR de cette proposition. »
En raison de l’absence de nuance de ses objections, du ton impétueux avec lequel elles ont été proférées et des accusations à propos d’Andresen, les réactions à ce message ont été loin d’être positives. Certains ont perçu l’initiative de Dashjr comme un appel haineux à la foule pour un débat technique qui aurait dû se limiter aux développeurs.
Que Dashjr soit l’un des contributeurs les plus fantasques, connu pour ses longs argumentaires en faveur de systèmes de nombres alternatifs et sa forte foi chrétienne n’a pas aidé non plus. Un utilisateur du forum a déclaré que les commentaires de Dashjr le faisaient paraître « mentalement instable » [18], un autre qu’il ne voulait pas du tout se soucier des détails, il faisait simplement confiance à Andresen [19].
En réponse, Dashjr a redoublé ses objections à la proposition P2SH pour des raisons philosophiques, contestant non seulement ses mérites techniques mais ses implications pour la gouvernance : « Si vous voulez une monnaie monarchique, pourquoi ne pas simplement utiliser l’USD de la Fed ? » Pour ses détracteurs c’était lui, au contraire, qui luttait pour le pouvoir [20].
Sans reculer, Dashjr coda une version alternative de P2SH, appelée CheckHashVerify (CHV). CHV était pour l’essentiel une implémentation P2SH différente – mais elle ne nécessitait pas une interprétation non conventionnelle des sorties de transaction. CHV impliquait un nouvel op code qui, comme OP_EVAL, pourrait se dissimuler dans un des op codes non utilisés.
Mais pour Andresen, qui appréciait peu les invectives publiques, il était trop tard les débats additionnels [21] : « Luke, tu testes ma patience. Je vais m’éloigner du code pendant quelques jours pour me calmer avant de faire quelque chose de stupide. »
Genjix s’en mêle
Comme la conception P2SH d’Andresen (maintenant simplement appelée P2SH) était largement considérée comme la solution la moins mauvaise, Dashjr s’est retrouvé avec peu de défenseurs.
Il reviendrait à Amir Taaki [sous le pseudonyme de Genjix] d’être la voix de la minorité et de prendre au sérieux ces préoccupations marginales – mais pas parce qu’il s’opposait à la solution d’Andresen ou qu’il était nécessairement d’accord avec celle de Dashjr. Le développeur, alors au début de la vingtaine, était déjà l’un des contributeurs les plus francs de Bitcoin, et bien qu’il ne soit pas encore devenu le hackeur anarchiste faisant la Une des journaux, vivant dans des squats et voyageant avec des armes imprimés en 3D, sa façon de considérer Bitcoin comme un mouvement politique « anti-establishment » l’avait rendu méfiant à l’égard des processus de développement. Il préférait que les décisions prennent du temps et impliquent la plus large base possible d’utilisateurs.
À son avis, Bitcoin ne devait pas être dirigé par une petite cabale de développeurs. Taaki était fermement convaincu que toute personne intéressée par le projet devrait être consciente des compromis et, dans la mesure du possible, participer à la prise de décision : « Je préférerais que les gens aient leur mot à dire en la matière même si cela complique le travail des développeurs et que ça les oblige à expliquer leurs décisions », a-t-il déclaré à d’autres développeurs [22]. « J’appréhende de dire aux utilisateurs que ce sera ainsi, qu’ils n’ont pas leur mot à dire, et de le faire un doigt d’honneur. »
Même si Taaki convenait que la différence entre la proposition P2SH d’Andresen et CHV de Dashjr était minime, il s’obstinait à considérer que l’implication des utilisateurs dans le processus de développement était fondamentale : « Ma crainte c’est qu’un jour Bitcoin soit corrompu. Considérez cet examen supplémentaire comme une opportunité de créer une culture d’ouverture ».
À cet effet, Taaki a écrit un article de blog dans lequel il a présenté les deux propositions (P2SH et CHV) et leurs différences [23]. Les utilisateurs doivent avoir le choix, tel était le message de Taaki, mais aussi : « Le vote est basé sur la puissance minière. »
Une situation inextricable
Avec ces mots, Taaki montrait du doigt l’éléphant au milieu de la pièce. Certes, Nakamoto avait adopté des soft forks, mais à la fin de 2011, le réseau ne fonctionnait plus comme à l’époque du fondateur.
Lorsque Nakamoto a publié le livre blanc en 2008, il a supposé que la preuve de travail serait fournie par des utilisateurs utilisant des ordinateurs personnels : « La preuve de travail c’est à peu près un CPU = un Vote », écrivait-il alors. N’importe quel utilisateur pourrait ainsi être un mineur et sécuriser le réseau en proposant des blocs, en validant les transactions envoyées par des pairs et en appliquant les règles du code rédigé par les développeurs.
Mais quelques années après le lancement du logiciel, ce modèle était devenu obsolète. Depuis que Lazlo Hanyesz (mondialement connu pour son goût pour les pizzas) avait compris qu’on pouvait générer des bitcoins en utilisant la puissance d’une carte graphique, le passe-temps de quelques mineurs s’était transformé en activité entrepreneuriale.
À peu près au même moment, Marek « Slush » Palatinus a introduit une méthode qui permettait aux mineurs de mettre en commun la puissance de hachage et partager les bénéfices. Cela rendait l’exploitation minière moins aléatoire pour en faire une source de revenus stable.
À la fin de 2011, trois pools seulement – DeepBit, Slush Pool et BTC Guild – contrôlaient bien plus de la moitié de la puissance de hachage. Au lieu d’un CPU, un vote, la plupart des « votes » étaient désormais entre les mains du petit collège électoral que composait les opérateurs de pools de minage.
Pour certains, c’était la preuve que quelque chose n’allait pas sur le réseau Bitcoin: « Que les [pools de minage] décident seuls d’un changement du protocole est une farce électorale », dira le développeur Midnightmagic [24]. Pour d’autres, la centralisation du minage était une béquille acceptable, un moyen de gérer plus facilement les soft forks et donc de les rendre moins risqués. Après tout un déploiement sécurisé ne nécessitait désormais que l’approbation d’une poignée d’exploitants de pools de minage.
Maxwell, par exemple, semblait résigné à cette réalité insatisfaisante [25] : « C’est un bon mécanisme à utiliser pour le futur… mais espérons que nous n’arriverons pas cette foutue situation où Bitcoin ne serait plus décentralisé. »
Voter ou ne pas voter ?
Que les propositions conflictuelles d’Andresen et de Dashjr en viennent à incarner des points de vue opposés sur la gouvernance Bitcoin ne faisait que compliquer les choses. Jusque-là, les développeurs avaient toujours parlé du prochain soft fork comme une sorte de vote : les mineurs pouvaient appliquer les nouvelles règles décrites par P2SH (ou OP_EVAL) avec une majorité de hachage, donc un vote était censé évaluer la probabilité de ce résultat.
Mais le vote omettait certaines nuances techniques. Les développeurs ne demandaient pas exactement aux mineurs ce qu’ils pensaient des nouvelles règles, mais plutôt s’ils s’engageaient à appliquer telle mise à jour. De ce point de vue, il était logique pour les développeurs qu’une seule proposition soit soumise aux utilisateurs et aux mineurs : « Le système Bitcoin n’est pas prêt pour une élection à la majorité. Ni une majorité de puissance de hachage, ni une majorité d’utilisateurs, ni une majorité financière », disait Maxwell, agacé par Taaki qui présentait ce processus comme un vote [26].
Maxwell était convaincu que les « votes » des mineurs devraient être limités, comme ils l’étaient dans le logiciel lui-même, à la sélection des transactions – et non pas aux règles de l’ensemble du protocole : « Que se passe-t-il si une super-majorité – même 100% – des mineurs actuels décident que la subvention devrait être pour toujours de 50 BTC pour toujours ?… RIEN. Les mineurs qui modifient cette règle dans leur logiciel cessent simplement d’exister dans le réseau Bitcoin », écrivait-il.
Dashjr n’était pas en désaccord avec Maxwell, mais en pratique, il lui était difficile de voir comment Bitcoin resterait sécurisé si les développeurs poussaient des changements sans le soutien des mineurs : « Les mineurs peuvent simplement refuser d’exploiter les transactions P2SH pour être immunisés contre les changements poussés par de l’équipe de développement […] Si les développeurs bloquent tous les mineurs, devinez ce qui se passe ? Cela expose le réseau à des attaques à 50%, il n’est plus sécurisé ! » [27].
Vu sous cet angle, il est plus facile de comprendre pourquoi Dashjr pensait qu’Andresen abusait de son rôle de développeur principal en tentant de pousser le P2SH seul. Si un mineur utilisait le logiciel standard pour miner un bloc, il voterait automatiquement en faveur de P2SH [28]. En réponse, Dashjr a écrit des correctifs qui permettraient à sa proposition de participer à « l’élection » afin que les mineurs puissent voter à la fois pour et contre P2SH et CHV.
Bien que peu de mineurs aient utilisé le code, l’opposition de Dashjr ne fut pas sans effet. Tycho, l’opérateur de DeepBit, alors le plus grand pool de minage du réseau, exprima alors son malaise face à son rôle dans l’évaluation du code. Comme il était clair pour lui qu’aucun consensus n’avait été trouvé parmi les développeurs il déclara : « Je ne veux pas devenir la seule entité à décider de cela » [29].
Dans l’impasse
En rejetant l’idée qu’un pool de minage pourrait, même par commodité, être utilisé pour influencer une décision de mise à jour, Tycho a changé la nature du débat. Sans son soutien, représentant plus de 30% de toute la puissance de hachage, P2SH aurait du mal à être activé.
Fin janvier, le « premier tour de scrutin » P2SH touchait à sa fin et il ne semblait pas qu’il allait atteindre le seuil requis. La mise à niveau devrait être retardée, une réalité qui a frustré non seulement Andresen, mais aussi d’autres développeurs. Sur IRC, Maxwell a déploré publiquement qu’il ne semblait pas y avoir d’issue en vue : « A moins que quelqu’un ne fixe une date limite, ce processus n’aboutira jamais car il y aura toujours quelqu’un dont la bonne idée a été laissée de côté. »
Andresen rejetterait la responsabilité du retard non pas sur l’avènement des pools de minage, mais uniquement sur Tycho, l’opérateur de DeepBit : « À l’heure actuelle, il semble qu’une seule personne ait suffisamment de pouvoir de hachage pour opposer son veto à tout changement » [31]. Andresen considérait la position de Tycho comme contraire à l’éthique : « Je pense que vous avez tort d’utiliser votre position de plus grand opérateur de pool pour aller à l’encontre du consensus général » [32].
Andresen eut beau exercer une pression publique, poussant les utilisateurs à demander à leurs pools de minage de se mettre à niveau – et offrant même de rembourser tous les fonds de DeepBit dans le cas où P2SH entraînait une perte financière – Tycho n’était toujours pas disposé à « voter » pour la proposition [33].
Face au retard, Andresen a tenté de mobiliser le public, persistant dans sa conviction que le choix entre P2SH et CHV aurait peu d’impact sur les utilisateurs : « Tous ces trucs [P2SH / CHV] c’est principalement des ingénieurs qui se disputent s’il vaut mieux utiliser un clou, une vis ou de la colle pour assembler deux morceaux de bois. Toutes les solutions fonctionneraient et les utilisateurs ordinaires ne remarqueraient aucune différence » [34].
À en juger par les réponses dans le fil de discussion, les utilisateurs de Bitcoin ont accepté le cadre fixé par Andresen, accusant Tycho de bloquer le fork et lui demandant de l’activer. Tycho, à son tour, s’est vivement opposé à la façon dont Andresen présentait les choses. Même avec 30% de puissance de hachage, il savait que les mineurs restants pouvaient passer outre, et il ne voulait pas être celui qui décide.
2ème round
P2SH n’ayant pas réussi jusqu’alors à accumuler suffisamment de puissance de hachage, Andresen fut obligé de discuter de sa proposition au grand jour et, pour sortir de l’impasse, il a commencé à accepter CHV comme une alternative potentielle. Commença alors un débat entre ceux qui pensaient que le choix entre P2SH et CHV appartenait aux mineurs et ceux qui étaient en faveur d’une prise de décision plus méritocratique : « En fin de compte, les mineurs sont les SEULES entité qui ont leur mot à dire sur des problèmes comme celui-ci », déclare ainsi Dooglus, un utilisateur de BitcoinTalk [35]. « Ce sont eux qui décident quelles transactions entrent dans des blocs. »
L’administrateur du forum, Theymos, rejetait catégoriquement cette idée : « Ceux qui ne minent pas peuvent cependant rejeter les blocs. Si suffisamment de clients font cela, les bitcoins minés n’auront aucune valeur » [36]. Theymos proposa alors qu’un certain cercle restreint d’experts s’engage dans une discussion de deux semaines au terme de laquelle il voteraient [37]. Que ce soit à cause de cette suggestion ou par pur hasard, Dashjr a rapidement créé un Wiki où une liste de développeurs réputé pouvaient exprimer leur préférence.
Au cours des jours suivant, Maxwell, Thomas et Wuille ont tous indiqué qu’ils seraient heureux d’accepter P2SH ou CHV, tout en précisant qu’ils préféraient le P2SH. O’Connor et Dashjr ont convenu que P2SH était acceptable, mais ont exprimé une préférence pour le CHV [38]. Sans surprise, Andresen s’est assuré d’influencer le scrutin en faveur du P2SH en opposant un « NON » retentissant contre la proposition du CHV.
De toute façon très peu de mineurs soutenaient sans doute CHV. À la mi-février, P2SH était pris en charge par 30% de la puissance de hachage, tandis que l’alternative de Dashjr était bloquée à environ 2%. Lors d’une réunion sur IRC, Dashjr a déclaré qu’il envisageait de retirer complètement CHV, acceptant à contrecœur la domination de P2SH [39]. Lors de cette même réunion, les participants ont convenu de fixer une deuxième date limite de vote pour le 1er mars.
À l’approche de la nouvelle date limite, davantage de mineurs se sont rassemblés derrière P2SH, amenant leur soutien près du seuil de 55% de la puissance de hachage. Bientôt, Tycho et Dashjr se sont retrouvés sans autre choix que d’accepter les préférences de leurs pairs [40].
Andresen a alors annoncé que le soft fork serait déployé et activé dans les 10 jours, et le 1er avril 2012, les nouvelles règles étaient appliquées [41].
P2SH, la première mise à jour du protocole depuis le départ de Satoshi, avait afin été promulgué.
Tempête dans un verre d’eau
Le processus politique difficile qui avait conduit à l’adoption du P2SH continuerait d’avoir un impact durable en dehors du logiciel lui-même. Au final, Andresen avait pu déployer la solution qu’il avait à la fois conçue et privilégiée. Si son leadership avait été remis en question pendant la crise, au final il a été fermement cimenté.
L’opinion publique, indifférente aux détails, s’est largement ralliée contre les actions de Dashjr, et dans une moindre mesure de Taaki, les jugeant inutiles et incendiaires [42]. Andresen est allé jusqu’à demander à Dashjr de cesser entièrement de contribuer à Bitcoin, bien qu’il semble qu’il ait reculé devant cette menace ou que Dashjr l’ait simplement ignorée [43].
Pendant ce temps, Maxwell est devenu l’un des principaux développeurs de Bitcoin, partageant l’accès au projet avec Andresen et les contributeurs Wladimir van der Laan et Jeff Garzik. Le ton était donné : ceux qui avaient pragmatiquement affiché leur soutien avaient été récompensé et les contributeurs hostiles ont été rejetés. Les débats avaient néanmoins fait apparaitre des différences idéologiques durables qui n’ont fait que s’enraciner.
Avec un nombre croissant d’utilisateurs de Bitcoin, P2SH est rapidement passé dans les usages, mais il constitue également les premier point majeur de désaccord entre les développeurs. Rappelant les événements un an plus tard au milieu d’une autre crise émergente, Andresen se vantait que P2SH avait validé son leadership et sa vision du projet [44] : « La taille du bloc sera augmentée« , affirmait en réponse à une vidéo produite par le développeur Peter Todd plaidant contre l’augmentation de la limite au début de l’année 2013 [45], « Votre vidéo ne fera qu’inquiéter beaucoup de gens pour rien, de la même manière que la proposition de Luke-Jr [CHV] l’année dernière n’a fait que provoquer une tempête dans un verre d’eau. »
Quelle gouvernance pour la première monnaie numérique décentralisée ? Si la question avait finalement été posée, il faudra une guerre beaucoup plus large [2] pour y répondre…
[1] Traduttore, traditore : Je livre ici une traduction non-professionnelle qui peut contenir des imprécisions, voire des erreurs. En cas de doute veuillez consulter le texte original.
[2] Allusion à la grande bataille autour de SegWit entre 2016 et 2017.
