Imaginez un réseau qui vaut des centaines de milliards de dollars et qui, depuis des années, traîne encore quelques failles techniques connues de presque tous les développeurs. Ces failles ne menacent pas le système demain matin, mais elles restent là, comme des portes mal fermées. Aujourd’hui, une proposition appelée BIP-54 revient sur le devant de la scène avec une ambition claire : les corriger une bonne fois pour toutes.
Pourquoi BIP-54 pourrait devenir le prochain soft fork de Bitcoin
Matt Corallo, développeur Bitcoin reconnu, a récemment estimé à 80 % la probabilité que ce BIP-54 soit la prochaine mise à jour majeure du protocole sous forme de soft fork. L’annonce a circulé après une discussion sur MARA Foundation TV, où il expliquait pourquoi il fallait d’abord nettoyer le consensus avant d’ajouter de nouvelles fonctionnalités.
Cette proposition n’est pas née hier. Elle trouve ses racines dans un travail de 2019, baptisé à l’époque « Great Consensus Cleanup ». Depuis, Corallo et Antoine Poinsot l’ont transformée en un Bitcoin Improvement Proposal formel. Le 22 mai 2026, la spécification a atteint le statut de « complete ». Pourtant, aucune date d’activation n’a encore été fixée.
Les estimations recueillies lors de la conférence TABconf à Atlanta parlent plutôt de 2027 au mieux, et plus vraisemblablement 2028 ou au-delà. Le calendrier reste donc flou, mais le sujet est bel et bien sur la table.
Les quatre failles que BIP-54 veut corriger
La spécification officielle cible précisément quatre points de faiblesse historiques. Voici ce qu’il faut retenir de chacun d’eux, reformulé de façon claire.
Les quatre points traités par BIP-54 :
- L’attaque timewarp sur l’ajustement de la difficulté
- Les blocs spécialement construits qui ralentissent la validation
- Les ambiguïtés dans les preuves d’inclusion de l’arbre de Merkle
- Le risque de transactions coinbase en double à certaines hauteurs
L’attaque timewarp et la manipulation des timestamps
Bitcoin ajuste sa difficulté de minage tous les 2016 blocs, soit environ toutes les deux semaines. Les mineurs indiquent l’heure à laquelle ils ont trouvé un bloc via un timestamp. En jouant sur ces timestamps, un acteur contrôlant une majorité de la puissance de calcul pourrait artificiellement faire baisser la difficulté.
Dans le scénario le plus extrême décrit par la documentation, la difficulté pourrait atteindre son minimum en seulement 38 jours. Les blocs se produiraient alors beaucoup plus rapidement que prévu. BIP-54 introduit des restrictions strictes sur les timestamps au début et à la fin de chaque période d’ajustement, avec une marge de deux heures pour les variations normales.
Il y a une longue liste de choses que nous savons qu’il faut vraiment nettoyer.
Matt Corallo
Les blocs trop lourds à valider
Certains blocs peuvent être construits de manière à exiger un volume de calculs disproportionné pour être validés. Sur des machines puissantes, cela peut prendre plusieurs minutes. Sur du matériel plus modeste, cela peut s’étendre à des heures. Un mineur malveillant pourrait ainsi ralentir ses concurrents.
BIP-54 limite le nombre d’opérations de vérification de signature à 2500 par transaction. Selon les auteurs de la proposition, cette simple contrainte pourrait réduire le temps de validation dans le pire des cas d’un facteur 40. L’idée n’est pas d’interdire des fonctionnalités, mais d’empêcher les abus qui freinent le réseau.
Les ambiguïtés de l’arbre de Merkle
Une transaction dont les données non-witness font exactement 64 octets peut, dans certaines conditions, ressembler à un nœud interne de l’arbre de Merkle. Un attaquant pourrait alors tromper des clients légers en leur faisant accepter une preuve d’inclusion frauduleuse.
La solution proposée est simple : invalider purement et simplement les transactions de cette taille précise. L’ambiguïté disparaît et les clients légers retrouvent une sécurité accrue.
Les transactions coinbase en double
Les transactions coinbase sont celles que les mineurs créent pour récupérer la récompense de bloc. Historiquement, des problèmes d’identification ont déjà existé. BIP-54 ajoute de nouvelles exigences sur certains champs de ces transactions pour éviter que le même problème ne réapparaisse à des hauteurs futures.
La spécification pointe le bloc 1 983 702 comme le premier moment où un doublon pourrait se produire avec les règles actuelles. En anticipant, le protocole se protège à long terme.
Maintenance ou innovation : le débat qui divise
Tout le monde n’est pas enthousiaste. Paul Sztorc, cofondateur de LayerTwo Labs, a qualifié l’éventuelle activation de BIP-54 de « assez déprimante » sur X. Pour lui, il s’agit surtout de maintenance pure, sans ajout de nouvelles capacités pour les utilisateurs.
Les développeurs interrogés à TABconf s’attendent pourtant majoritairement à ce que ce nettoyage soit le prochain soft fork. Le calendrier reste cependant très éloigné. Certains estiment que Bitcoin a du mal à activer de nouvelles mises à jour depuis Taproot en novembre 2021. Les désaccords sur les méthodes d’activation (signalement des mineurs versus deadline imposée par les utilisateurs) bloquent souvent les progrès.
Des propositions comme OP_CAT ou OP_CHECKTEMPLATEVERIFY (BIP-119) peinent également à rassembler un consensus suffisant. Pendant ce temps, d’autres sujets comme la résistance quantique (avec des idées comme BIP-360) commencent à émerger. BIP-54 se distingue en restant purement correctif.
Un processus d’activation plus clair pour l’avenir
Au-delà des corrections techniques, Corallo voit dans BIP-54 une opportunité de standardiser la façon dont les soft forks sont activés. Les débats autour de Taproot ont montré que le désaccord ne porte pas seulement sur le contenu des changements, mais aussi sur la méthode pour les déployer.
En utilisant cette mise à jour comme terrain d’essai, les développeurs pourraient définir un processus réutilisable. Les nœuds qui n’ont pas encore mis à jour resteraient compatibles, car les nouvelles règles sont plus strictes que les anciennes. Les opérateurs sont néanmoins encouragés à mettre à jour pour pouvoir les appliquer eux-mêmes.
Du côté des mineurs, les versions 29.0 et 30.0 de Bitcoin Core intègrent déjà certaines protections compatibles avec les restrictions proposées. Les pools de minage devront simplement s’assurer que leurs transactions coinbase respectent les nouvelles exigences.
Ce que BIP-54 change concrètement pour le réseau
Contrairement à une hard fork, un soft fork n’oblige personne à mettre à jour immédiatement. Les nœuds anciens continuent de voir les nouveaux blocs comme valides. Seuls ceux qui appliquent les nouvelles règles les font réellement respecter. C’est ce qui rend le déploiement plus souple, mais aussi plus lent.
Les corrections proposées n’ajoutent aucune fonctionnalité visible pour l’utilisateur final. Elles rendent simplement le protocole plus robuste face à des scénarios d’attaque connus. Dans un écosystème où la confiance repose sur la prévisibilité et la solidité, ce type de nettoyage a une valeur réelle, même s’il manque de « wow ».
Points clés à retenir :
- Quatre failles techniques connues depuis des années
- Pas de date d’activation confirmée, horizon 2027-2028+
- Compatibilité maintenue avec les nœuds non mis à jour
- Opportunité de clarifier le processus d’activation des soft forks
Le contexte plus large des mises à jour Bitcoin
Depuis Taproot, le rythme des évolutions du protocole a ralenti. Les discussions techniques sont souvent productives, mais le passage à l’activation bute régulièrement sur des désaccords de gouvernance. Certains développeurs plaident pour des fonctionnalités nouvelles qui ouvriraient la voie à des contrats plus complexes. D’autres, comme Corallo, estiment qu’il faut d’abord solidifier les bases.
Cette tension n’est pas nouvelle. Elle reflète la nature même de Bitcoin : un système où le changement doit être consensuel et extrêmement prudent. Chaque modification du consensus est un pari sur la stabilité à long terme. BIP-54 s’inscrit dans cette logique de prudence.
Les implications pour les mineurs et les opérateurs de nœuds
Pour les mineurs, l’impact principal concerne la construction des templates de blocs et le respect des nouvelles règles sur les timestamps et les coinbase. Les versions récentes de Bitcoin Core offrent déjà des protections. Les pools devront vérifier leurs scripts de coinbase.
Pour les opérateurs de nœuds complets, la mise à jour permettra d’appliquer eux-mêmes les restrictions. Ceux qui restent sur d’anciennes versions continueront de fonctionner, mais sans pouvoir rejeter les blocs qui enfreignent les nouvelles règles.
Les clients légers, quant à eux, bénéficieront d’une protection accrue contre les preuves de Merkle frauduleuses grâce à l’invalidation des transactions de 64 octets non-witness.
Pourquoi certains parlent de « nettoyage » plutôt que d’upgrade
Le terme « Great Consensus Cleanup » résume bien l’esprit de la proposition. Il ne s’agit pas d’ajouter des outils pour les développeurs d’applications, mais de retirer des angles morts du protocole. C’est moins spectaculaire qu’une nouvelle opcode, mais potentiellement plus important pour la solidité à long terme.
Corallo insiste sur le fait que ces problèmes sont « de véritables préoccupations », sans être des menaces immédiates. Le réseau fonctionne aujourd’hui. Mais laisser ces failles ouvertes indéfiniment n’est pas une stratégie viable pour un actif de cette taille.
Le calendrier et les incertitudes restantes
Même avec 80 % de chances selon Corallo, rien n’est acquis. L’activation d’un soft fork demande un large soutien de l’écosystème. Les discussions sur le mécanisme d’activation (miner signaling, user-activated soft fork, etc.) peuvent encore freiner le processus.
Les estimations de TABconf montrent un consensus relatif sur le fait que BIP-54 sera probablement le prochain, mais aussi un réalisme quant aux délais. Septembre 2027 est la date la plus optimiste entendue. La majorité des développeurs se projette plutôt en 2028 ou plus tard.
Ce que cela dit de l’état actuel de Bitcoin
Le fait qu’une proposition de nettoyage technique prenne autant de temps à se concrétiser en dit long. Bitcoin a atteint un niveau de maturité où la stabilité prime souvent sur la vitesse d’innovation. C’est à la fois une force et une contrainte.
D’un côté, le protocole résiste aux changements précipités. De l’autre, des corrections jugées nécessaires par une grande partie de la communauté technique mettent des années à aboutir. BIP-54 illustre parfaitement cette dualité.
Regard vers l’avenir des soft forks
Si BIP-54 parvient à établir un processus d’activation plus clair et accepté, il pourrait débloquer d’autres propositions qui attendent depuis longtemps. OP_CAT, CTV et d’autres idées techniques pourraient alors trouver un chemin plus fluide vers le consensus.
En attendant, le réseau continue de fonctionner. Les failles ciblées restent théoriques ou difficiles à exploiter à grande échelle. Mais le simple fait de les reconnaître et de proposer une solution structurée montre que la communauté technique reste attentive.
Synthèse des enjeux techniques
Pour résumer de façon concrète, BIP-54 s’attaque à des faiblesses qui touchent la sécurité et la performance du consensus. L’attaque timewarp pourrait permettre de manipuler la difficulté. Les blocs lourds à valider pourraient être utilisés pour retarder le réseau. Les ambiguïtés Merkle exposent les clients légers. Les doublons coinbase pourraient créer des problèmes d’identification à long terme.
Chaque correction est conçue pour rester compatible avec le passé tout en renforçant le présent. C’est la marque de fabrique des soft forks réussis dans l’histoire de Bitcoin.
L’importance de la pédagogie autour de ces changements
Beaucoup d’utilisateurs finaux ne suivent pas les détails techniques des BIP. Pourtant, la confiance dans le réseau repose en partie sur la capacité de la communauté à expliquer pourquoi certaines mises à jour sont prioritaires. Corallo et Poinsot ont fourni une spécification complète. Reste à ce que l’écosystème s’en empare et en discute de façon constructive.
Les forums de développeurs, les conférences comme TABconf et les discussions publiques jouent un rôle central. C’est là que se construit (ou se bloque) le consensus social nécessaire à toute évolution du protocole.
Un pas vers une meilleure gouvernance technique
Au-delà des quatre corrections, l’enjeu le plus durable pourrait être méthodologique. Si BIP-54 permet de tester et de valider un processus d’activation plus prévisible, il aura servi deux fois : une fois pour le code, une fois pour la gouvernance.
Dans un protocole où personne ne détient le pouvoir de décision unilatéral, la capacité à s’accorder sur la façon de changer les règles est presque aussi importante que les règles elles-mêmes.
Conclusion ouverte sur l’évolution de Bitcoin
BIP-54 n’est pas une révolution. C’est un nettoyage soigneux de failles connues depuis longtemps. Matt Corallo lui donne de fortes chances de devenir le prochain soft fork. Les développeurs présents à TABconf semblent partager cette intuition, tout en restant réalistes sur les délais.
Que la proposition aboutisse en 2027, 2028 ou plus tard, elle illustre parfaitement l’état d’esprit actuel de Bitcoin : prioriser la robustesse, progresser lentement, et chercher à chaque étape à améliorer non seulement le code, mais aussi la façon dont les changements sont adoptés.
Le réseau a survécu et prospéré en restant prudent. BIP-54 s’inscrit dans cette tradition. Reste à voir si l’écosystème saura transformer cette proposition technique en réalité activée, et si le processus d’activation qui en découlera servira de modèle pour les années à venir.
En attendant, les quatre failles restent documentées, la spécification est prête, et la discussion continue. C’est ainsi que Bitcoin avance : pas à pas, en s’assurant que chaque marche est solide avant de monter la suivante.
