Après l'échec du BIP-110, le prochain « soft fork » du Bitcoin s'apprête à faire l'objet d'une confrontation décisive

Le BIP-54, officiellement appelé « Consensus Cleanup », apporterait quatre modifications mineures aux règles fondamentales de Bitcoin. La proposition vise à corriger d’anciennes failles et des cas limites inhabituels, et non à ajouter de nouvelles façons d’utiliser le Bitcoin. Ses partisans affirment que cette distinction est importante : il s’agit d’une maintenance préventive pour un réseau dont la valeur est aujourd’hui bien supérieure à ce qu’elle était lorsque bon nombre de ses règles ont été rédigées.

Les auteurs de la proposition sont Antoine Poinsot, un contributeur de Bitcoin Core associé à Chaincode Labs, et Matt Corallo, un développeur Bitcoin de longue date. C’est M. Corallo qui a pour la première fois évoqué cette idée générale en 2019. Antoine Poinsot a relancé et approfondi ce travail fin 2023 et début 2024, et la proposition a reçu sa désignation officielle BIP-54 en avril 2025. La spécification a été déclarée achevée en mai 2026 après une phase de tests et de mise en œuvre.

La proposition vise à combler quatre lacunes anciennes

La première correction vise à remédier à une attaque potentielle de type « timewarp » (déplacement temporel) visant la difficulté de minage du Bitcoin. Le Bitcoin recalcule la difficulté de minage tous les 2 016 blocs, soit environ toutes les deux semaines, afin de maintenir la production de blocs à un rythme proche d’un bloc toutes les dix minutes. Une majorité de la puissance de minage du réseau pourrait exploiter la manière dont Bitcoin mesure le temps sur ces périodes, en utilisant des horodatages manipulés pour donner l’impression que les blocs sont produits plus lentement qu’ils ne le sont en réalité.

À terme, cela pourrait faire baisser la difficulté de minage. Dans un cas extrême, un attaquant disposant d’une majorité du « hash rate » (la puissance de calcul utilisée pour miner des bitcoins) pourrait ramener la difficulté à son niveau le plus bas en environ 38 à 40 jours. Cela pourrait théoriquement permettre à l’attaquant de produire des blocs bien plus rapidement que la normale, de créer rapidement de nouvelles pièces, d’étoffer la base de données du réseau contenant les pièces non dépensées et de perturber les contrats de paiement basés sur le temps, tels que ceux utilisés par le protocole de deuxième couche, le Lightning Network.

Le BIP-54 ajouterait des limites d’horodatage au début et à la fin de chaque période de 2 016 blocs. Ces règles visent à bloquer la méthode classique dite « timewarp » ainsi qu’une variante associée connue sous le nom d’attaque Murch-Zawy, tout en laissant le minage ordinaire inchangé.

Le BIP-54 vise également à protéger les petits opérateurs de nœuds

La deuxième modification vise les « blocs empoisonnés », c’est-à-dire des blocs valides délibérément conçus pour que leur vérification par les ordinateurs prenne un temps anormalement long. Certains scripts de transaction Bitcoin plus anciens peuvent nécessiter plusieurs minutes, voire plusieurs heures, de traitement sur du matériel standard. Un attaquant pourrait les utiliser pour ralentir le réseau, augmenter le risque que les mineurs gaspillent leur travail sur des blocs obsolètes et compliquer l’exploitation de nœuds Bitcoin indépendants par les utilisateurs. Le BIP-54 plafonnerait les anciennes transactions antérieures à Segregated Witness (SegWit) à 2 500 opérations de signature héritées. Les opérations de signature sont les vérifications cryptographiques utilisées pour prouver qu’une personne est autorisée à dépenser des bitcoins. Les transactions normales en utilisent beaucoup moins, et les transactions SegWit et Taproot ne seraient pas soumises à cette limite. Les partisans de cette mesure estiment que ce changement pourrait réduire la charge de vérification dans le pire des cas d’environ 40 fois dans certains cas.

Le troisième changement résout un problème lié à l’arbre de Merkle de Bitcoin, le système qui regroupe les transactions en un seul résumé pour chaque bloc. Une transaction d’une longueur exacte de 64 octets peut ressembler à un élément interne de cette structure. Cela permet de falsifier une preuve susceptible d’induire en erreur certains portefeuilles à vérification simplifiée des paiements (SPV) et de les amener à accepter une transaction qui n’a jamais été confirmée.

Le BIP-54 rendrait simplement invalides les transactions de 64 octets. Ces transactions sont non conformes à la norme depuis des années et sont rarement utilisées. Les partisans de la proposition font valoir que leur interdiction résout le problème sous-jacent de manière plus nette que de s’attendre à ce que chaque portefeuille léger utilise une solution de contournement.

Une règle définitive pourrait simplifier l’avenir du Bitcoin

Le quatrième changement concerne les transactions « coinbase », ces transactions spéciales par lesquelles les mineurs reçoivent des bitcoins nouvellement émis ainsi que les frais de transaction. Au cours des premières années du Bitcoin, des transactions « coinbase » identiques apparaissaient dans plusieurs blocs, ce qui entraînait la disparition des sorties non dépensées de la transaction la plus ancienne. Bitcoin a ajouté des contrôles pour empêcher que cela ne se reproduise, mais ces contrôles compliquent la validation des blocs.

Le BIP-54 exigerait que les nouvelles transactions « coinbase » incluent des paramètres liés à la hauteur du bloc, c’est-à-dire à sa position dans la blockchain. Cela garantirait leur unicité à l’avenir et pourrait à terme permettre aux nœuds de supprimer les anciens contrôles de transactions en double. Ce changement pourrait simplifier la validation et soutenir de futures conceptions visant à réduire la charge de stockage liée à l’exploitation d’un nœud complet.

La position de F2pool complique l’activation

Les arguments techniques en faveur du BIP-54 n’ont pas mis fin au débat politique. Wang Chun, cofondateur du grand pool de minage F2pool, a déclaré le 10 août qu’il ne soutenait pas la proposition. Il a expliqué que F2Pool mettrait à jour ses nœuds de minage si le BIP-54 obtenait la majorité requise via un processus d’activation standard BIP-9, mais que le pool ne donnerait pas de signal en ce sens au préalable.

L’objection de Chun, exprimée dès le mois d’avril sur X, porte principalement sur la procédure et les priorités. Il a fait valoir que regrouper quatre modifications revient à intégrer des mesures sans rapport entre elles dans un seul projet de loi. Il estime que plusieurs de ces risques sont trop éloignés pour justifier la coordination, les mises à jour logicielles et l’attention de la communauté requises pour un soft fork, qui modifie les règles de Bitcoin d’une manière que les anciens logiciels pourraient ne pas appliquer.

Les partisans voient ce regroupement sous un autre angle. Ils font valoir que chaque modification du consensus entraîne un coût social élevé ; ainsi, combiner plusieurs correctifs défensifs permet de réduire le nombre d’opérations d’activation complexes à l’échelle du réseau. Ils ajoutent que la valeur croissante du Bitcoin donne aux attaquants davantage de raisons d’explorer des failles qui semblaient autrefois purement théoriques.

L’échec du BIP-110 renforce la prudence

Ce débat intervient juste après l’échec du BIP-110, une proposition distincte qui visait à restreindre temporairement les données non financières stockées dans les transactions Bitcoin. Elle visait les pratiques associées aux inscriptions « Ordinals », aux données OP_RETURN volumineuses et à certains stockages de données basés sur Taproot. Son seuil d’activation plus bas n’a pas réussi à susciter un soutien significatif de la part des mineurs, et une « petite chaîne » mettant en œuvre la proposition s’est enlisée après avoir produit une poignée de blocs. Cet épisode ne fait pas du BIP-54 une proposition similaire. Le BIP-54 n’ajoute ni ne supprime de fonctionnalités de script à usage général, et ne constitue pas non plus une voie vers les « covenants » ou l’OP_CAT, des propositions qui élargiraient les options de dépenses programmables de Bitcoin. Néanmoins, le BIP-110 a démontré à quelle vitesse une mise à jour controversée peut déboucher sur un débat plus large quant à savoir qui devrait décider de l’avenir de Bitcoin.

Le BIP-54 est déjà actif à des fins de test sur Bitcoin Inquisition, un environnement de test basé sur Signet, et les versions actuelles de Bitcoin Core ont adopté des mesures de protection connexes. Certains pools de minage, notamment MARA et ViaBTC, ont volontairement commencé à produire des transactions coinbase compatibles. Mais les paramètres d’activation officiels n’ont pas encore été définis, et un vote sur le réseau principal reste en cours.

La question suivante est de savoir si les développeurs, la communauté, les entreprises, les opérateurs de nœuds et les mineurs peuvent s’accorder sur le fait que la correction de risques connus mais rarement exploités mérite un nouvel effort de coordination de l’ampleur d’un hard fork. Les lecteurs sont invités à suivre l’annonce d’une proposition officielle de signalisation BIP-9, les annonces supplémentaires concernant l’état de préparation des mineurs, et à observer si la résistance de F2pool empêchera l’obtention du large soutien dont les mises à jour de Bitcoin ont traditionnellement besoin.