Modern : l'activation du soft fork se prépare

Ce texte, initialement publié sur la mailing list bitcoin-dev, revient sur plusieurs principes qu'une activation devrait respecter. Maxwell rappelle d'abord qu'un changement ne doit pas être activé s'il se heurte à une objection "significative, raisonnable et ciblée". Il ajoute qu'il faut aussi éviter d'activer trop vite, afin de laisser le temps à une adoption importante au niveau des nœuds, et ne pas perdre inutilement de la puissance de calcul chez les mineurs non mis à jour.

Les exigences mises en avant

Selon lui, la puissance de calcul peut servir à sécuriser la période de transition. C'est la raison pour laquelle les soft forks récents demandaient 95 % de hashpower prête à appliquer les nouvelles règles. Pour Maxwell, ce mécanisme permet d'éviter une rupture du réseau pendant la mise à jour, à condition qu'il soit vraiment utilisé pour cela.

Il insiste aussi sur un point politique : la communauté doit pouvoir aller de l'avant sans être bloquée par des objections qu'il juge déraisonnables, par exemple lorsqu'une critique vise le fait qu'un soft fork ne corrige pas un autre problème. "Nous ne prenons pas de bonnes décisions d'ingénierie en "emballant" des fonctionnalités sans rapport pour permettre des compromis politiques", écrit-il.

BIP 9, BIP 8 et calendrier d'activation

Maxwell estime que BIP 9 couvre plutôt bien les points 2 à 4 de sa liste, et qu'avec une forte participation de la communauté, il peut aussi répondre au premier. En revanche, il juge que le point 5 est celui sur lequel ce modèle échoue le plus souvent. BIP 8, proposé comme alternative, a selon lui été pensé en réponse à ces limites, mais une mise en œuvre naïve ne remplit pas les critères essentiels et peut donner l'impression que les développeurs décident des règles de consensus.

Il cite ensuite un passage issu de la proposition Great Consensus Cleanup, qui défendait un déploiement via BIP 9 tout en laissant ouverte une activation par flag day si un large accord se dégageait à l'échéance. Maxwell dit rester favorable à ce modèle, qu'il attribue à Greg Maxwell, et propose plus concrètement un schéma en trois étapes : un déploiement BIP 9 avec un horizon d'un an et 95 % de mineurs prêts, puis une période de six mois pour analyser l'absence éventuelle d'activation, puis, si nécessaire, une option permettant aux utilisateurs d'opter pour un déploiement BIP 8 avec un horizon de 24 mois.

Il conclut que ce dispositif laisserait un temps long pour une activation standard, tout en respectant les objectifs liés à l'objection raisonnable et à la sécurité du réseau. "Développer Bitcoin n'est pas une course", écrit-il, ajoutant que, si besoin, attendre 42 mois permettrait d'éviter de créer un précédent négatif.