Bitcoin Core prépare une défense contre une ancienne attaque sur l'ajustement de difficulté

• Le PR #35949 a été fusionné le 7 septembre 2026 dans Bitcoin Core.
• Le changement corrige la façon dont le modèle du dernier bloc de chaque période est constitué.

Bitcoin Core, le logiciel de référence du réseau Bitcoin, a changé le 7 septembre la manière dont les mineurs préparent l'un des blocs de chaque période. Cet ajustement est l'œuvre du développeur Fabian Jahr.

Il s'agit d'une étape préalable à une future correction plus importante. Pour l'instant, aucune règle du réseau n'a changé : seul le logiciel qui assemble les blocs avant leur minage a été ajusté.

La correction vise une faille ancienne et bien connue : le soi-disant time warp attack. C'est une astuce qui permettrait à quelqu'un ayant un pouvoir de minage (hashrate) élevé de tricher sur l'heure des blocs.

Chaque bloc de Bitcoin porte une marque temporelle. Si un mineur pouvait falsifier cette marque de manière systématique, il pourrait tromper le réseau en lui faisant croire qu'il s'est écoulé moins de temps que la réalité entre les blocs. Cela réduirait artificiellement la difficulté de minage, et avec une difficulté plus basse, ce mineur gagnerait des blocs plus rapidement que ce qui lui revient, prenant ainsi la récompense à d'autres mineurs.

Que cette erreur ne soit toujours pas complètement corrigée, plus d'une décennie après sa découverte, n'est pas un oubli. Changer une règle du consensus de Bitcoin exige que presque tout le réseau ---mineurs, échanges, ceux qui exécutent un nœud--- soit d'accord et prêt en même temps. Cet accord collectif, plus que la difficulté technique, est ce qui prend des années à se construire.

C'est pourquoi la solution n'attaque pas ce problème seule, mais en même temps que trois autres failles anciennes du design original de Bitcoin. La proposition qui les regroupe s'appelle BIP54 et vise à corriger, d'un seul coup : le time warp attack, les blocs conçus pour être lents à valider, une ambiguïté dans les arbres Merkle qui pourrait être utilisée pour falsifier des preuves de transaction, et une négligence qui permettrait de dupliquer des transactions coinbase (celles créées lors du minage du bloc). Regrouper ces quatre corrections évite que le réseau ait à passer par le long processus d'accord une fois pour chacune.

Que corrige concrètement le nouveau changement

Le changement dont il est question dans cet article est documenté dans la demande de tirage 35949 du dépôt officiel de Bitcoin Core, et s'occupe spécifiquement du premier de ces quatre problèmes : le time warp attack. Les trois autres ---blocs lents à valider, l'ambiguïté dans les arbres Merkle et les transactions coinbase dupliquées--- n'ont toujours pas de changement de logiciel équivalent jusqu'à présent.

Imaginons que l'horloge de l'ordinateur d'un mineur soit mal configurée et indique une heure antérieure à la réalité. Avant ce changement, si cela se produisait juste au moment de préparer le dernier bloc d'une période de difficulté, le logiciel pouvait se bloquer.

Il calculait mal le temps minimum autorisé et n'arrivait pas à assembler un bloc valide à miner. En pratique, ce mineur se retrouvait sans pouvoir travailler jusqu'à ce que son horloge se corrige seule.

Fabian Jahr, auteur du changement, a expliqué dans le dépôt lui-même que ce scénario est peu probable sur le réseau principal de Bitcoin, car il nécessiterait une erreur d'horloge très importante. C'est plus fréquent sur les réseaux de test, où les conditions sont moins stables.

Néanmoins, Bitcoin Core a préféré le résoudre avant que cela ne devienne un problème réel. Avec le nouveau code, lorsque l'horloge d'un nœud est en retard, le logiciel lui-même met l'heure correcte à la proposition de bloc, au lieu de rester bloqué. Cet ajustement fonctionne déjà sur le réseau principal et sur les réseaux de test, même si BIP54 lui-même n'est pas encore actif sur aucun d'eux.

Pourquoi Bitcoin corrige ses erreurs si lentement

Ce cas montre un schéma rarement vu de l'extérieur : ceux qui développent Bitcoin Core ne corrigent pas les failles de consensus d'un seul coup. Ils préparent d'abord le logiciel qui fonctionne << autour >> de la règle ---dans ce cas, le minage--- et ensuite, s'il y a suffisamment de soutien de la communauté, ils activent le changement de fond.

Cet ordre a une raison simple : si la nouvelle règle était activée sans que le logiciel de minage soit prêt, des problèmes évitables apparaîtraient, comme des nœuds qui ne peuvent soudainement plus miner à cause d'une simple erreur d'horloge. Les développeurs préfèrent nettoyer ces détails avant de demander à tout le réseau de faire un pas qui ne peut pas être annulé.

L'histoire même de BIP54 confirme cette patience. L'idée est née en 2019, sous l'égide de Matt Corallo, et est restée en attente pendant des années jusqu'à ce qu'Antoine Poinsot la reprenne en 2023, comme l'indique le texte de la proposition publié dans le dépôt de BIPs de Bitcoin. Ce qui semble à première vue être de la lenteur est, en réalité, le même soin qui évite qu'un réseau qui gère des milliards de dollars adopte des changements sans un débat suffisant.

Cela ne signifie pas que le time warp attack soit inoffensif en attendant. C'est toujours une possibilité réelle pour quiconque a suffisamment de pouvoir de minage, et cela oblige l'industrie à admettre que ce risque reste ouvert. La différence est qu'il existe maintenant un chemin concret, avec un code déjà approuvé, pour le fermer.