Bitcoin a un correctif prêt pour quatre failles connues. Personne ne peut l'activer

Le 8 août 2026, une chaîne de blocs a cessé de respirer. Deux blocs en huit heures, quand celle d'à côté en produisait quarante-huit. Les nœuds restés dessus appliquaient des règles que presque personne d'autre n'appliquait, et rien, dans le protocole, ne prévoyait d'arbitre pour trancher. Ce qui s'est joué là ne décide pas du sort d'une proposition anti-spam. C'est la démonstration, en direct, de qui détient aujourd'hui le pouvoir de modifier Bitcoin. La même semaine, ce déplacement du pouvoir s'est répété sur trois autres terrains.

Le vote qui n'a pas eu lieu

Bitcoin n'a ni assemblée d'actionnaires, ni fondation qui tranche. Une modification des règles y prend la forme d'un soft fork, un durcissement que les anciens nœuds continuent d'accepter. Pour éviter que le réseau se scinde, une large majorité de la puissance de calcul doit signaler son accord dans les blocs qu'elle produit. Ce signalement est tout ce qui tient lieu de gouvernance.

Un déploiement standard, décrit par le BIP-9, réclame 95 % de ce signalement. Le BIP-110, qui proposait de limiter temporairement les champs de données au niveau du consensus, avait abaissé la barre à 1109 blocs sur 2016, soit 55 %, un écart que son texte justifie par l'urgence du sujet et par un déploiement conçu pour expirer au bout d'un an.

La barre abaissée n'a pas été approchée. Le 8 août, premier jour de signalement obligatoire, le signalement a plafonné à 2,53 %, une mesure relevée par deux briefs CDR indépendants les 10 et 11 août. Le seuil avait été abaissé de 40 points. Le signalement n'en a pas atteint le vingtième.

Les nœuds qui appliquaient la règle se sont retrouvés isolés sur une chaîne minoritaire figée à la hauteur 961 633, sans aucune protection contre le rejeu prévue par le texte. Le 9 août, le changelog officiel de la proposition a fait passer son statut à Closed, avec la mention d'une scission de chaîne à minage paralysé.

Le correctif que le débat sur les données n'a jamais concerné

Pendant que cette bataille occupait la place, une autre proposition attendait, et elle n'a rien à voir avec les données arbitraires. Le BIP-54, intitulé Consensus Cleanup, porte au dépôt officiel le statut Complete. Son résumé énumère quatre corrections : l'attaque timewarp, le temps de validation d'un bloc dans le pire cas, les faiblesses de l'arbre de Merkle, et les transactions dupliquées sans recours à la validation décrite par le BIP-30.

Ces quatre points ne sont pas théoriques. Le texte décrit un attaquant majoritaire capable, par la faille timewarp, d'abaisser arbitrairement la difficulté, jusqu'à son minimum en trente-huit jours dans le pire cas, et des blocs spécialement construits dont la validation peut prendre jusqu'à plusieurs minutes sur du matériel haut de gamme, et quelques heures sur des machines modestes, de quoi attaquer ses concurrents.

Aucune de ces corrections ne touche aux inscriptions, aux jetons BRC-20 ni à la taille des charges de données. Le débat public range pourtant les deux propositions dans le même camp.

Le même verrou, deux serrures différentes

Deux objets sans rapport, un seul point de blocage : les opérateurs de pools. Le texte du BIP-54 s'adresse d'ailleurs directement à eux, en notant que la transaction coinbase est généralement fabriquée par leur logiciel et en les invitant à le mettre à jour. Les objections résiduelles portent sur deux points opérationnels de cette nature : l'obligation d'inscrire dans le champ locktime de la coinbase la hauteur du bloc moins un, et l'invalidation des transactions dont la taille sérialisée sans témoin fait exactement 64 octets.

Un opérateur de minage majeur s'est publiquement opposé à la proposition le 10 août, d'après une source unique que CDR n'a pas recoupée sur une déclaration d'origine. L'ampleur du soutien chez les autres pools reste inconnue.

Le veto s'exerce depuis une industrie qui rétrécit. Le hashrate moyen sur trente jours est passé de 1 108 EH/s en novembre 2025 à 898 EH/s en août 2026, soit une contraction de 19 % en neuf mois, la plus longue jamais enregistrée sur le réseau, d'après les mesures Glassnode relevées par CDR le 7 août.

La question du pouvoir s'est posée une seconde fois la même semaine, un étage plus haut. Le 11 août, Luke Dashjr, crédité au texte du BIP-110 pour le brouillon d'origine et les conseils, a perdu son accès d'éditeur au dépôt qui héberge les propositions, environ vingt-six heures après le dépôt d'une motion par un autre éditeur. Le motif exact n'est pas établi par une source primaire, et il ne se déduit pas du calendrier.

Ce que l'immobilité protège, et ce qu'elle coûte

L'immobilisme a sa lecture solide : si personne ne peut modifier Bitcoin unilatéralement, la règle monétaire tient, et c'est exactement la propriété qu'on attend d'une réserve de valeur. Un protocole difficile à changer est un protocole difficile à corrompre.

La lecture inverse s'appuie sur le même fait. Le veto n'appartient ni aux détenteurs ni à ceux qui écrivent le code, il appartient à une poignée d'opérateurs dont l'économie se dégrade et dont l'électricité se réoriente déjà. Une vulnérabilité documentée et non corrigée n'est pas une propriété, c'est une dette, et elle se paie au premier exploit.

Le piège pour le lecteur est de croire que ce blocage protège Bitcoin du spam. Il bloque aussi des correctifs de sécurité qui n'ont aucun rapport avec le spam. L'épisode Coldcard de juillet a rappelé la mécanique du côté des portefeuilles : un correctif ne protège jamais ce qui a déjà été exposé. Sur une couche de consensus, la contrainte est plus dure encore, puisque le correctif n'existe qu'une fois activé.

Le précédent qui compte n'est pas SegWit mais Taproot, dernier changement de consensus déployé sur Bitcoin, activé à la hauteur 709 632 en 2021. Son déploiement avait déjà dû abaisser le seuil à 1815 blocs sur 2016, soit 90 % au lieu de 95 %, et s'était doublé d'une proposition de signalement obligatoire dont le texte disait pourquoi en une phrase : sans elle, les mineurs auraient la capacité de bloquer indéfiniment l'activation d'un soft fork qui fait pourtant consensus. Cinq ans plus tard, la même mécanique tourne à vide, et cette fois sans issue de secours.

Ce qui se surveille tient en deux points : le dépôt effectif d'un vote BIP-9 sur le BIP-54, et le positionnement public des autres pools majeurs. Au seuil que réclame un déploiement standard, chaque ralliement pèse.

Questions fréquentes

Le BIP-54 a-t-il un rapport avec les Ordinals ou le spam de données ?
Non. Le texte officiel énumère quatre corrections : l'attaque timewarp, le temps de validation d'un bloc dans le pire cas, les faiblesses de l'arbre de Merkle et les transactions dupliquées sans recours à la validation BIP-30. Aucune ne porte sur les données arbitraires ni sur les inscriptions.

Pourquoi le BIP-110 a-t-il échoué alors que son seuil avait été abaissé à 55 % ?
Parce que le signalement a plafonné à 2,53 % le 8 août 2026, environ 52,5 points sous un seuil déjà réduit de 40 points par rapport au standard BIP-9.

Un nœud qui appliquait les règles du BIP-110 risquait-il quelque chose ?
Il se retrouvait sur une chaîne minoritaire au minage quasi arrêté, figée à la hauteur 961 633, et le texte de la proposition ne prévoit aucun mécanisme de protection contre le rejeu. Une transaction diffusée sur cette chaîne reste valide sur la chaîne principale.

Qui décide de l'activation d'un changement de consensus sur Bitcoin ?
Personne, au sens institutionnel. Il n'existe ni vote d'actionnaires ni fondation qui tranche. Une proposition n'entre en vigueur que si une part suffisante de la puissance de calcul la signale dans les blocs qu'elle produit, ce qui place la décision entre les mains des opérateurs de pools.