TIME WARP
Attaque théorique sur le mécanisme d’ajustement de la difficulté de Bitcoin qui exploite une faille dans la manière dont les horodatages des blocs sont vérifiés à la frontière entre deux périodes de retarget. Tous les 2 016 blocs, le protocole recalcule la cible de difficulté en comparant l’horodatage du premier bloc de la période avec celui du dernier. L’attaque consiste, pour un mineur qui contrôle une majorité de la puissance de calcul, à manipuler ces horodatages : il fixe les horodatages de presque tous les blocs de la période au minimum autorisé par la règle Median Time Past (MTP), puis attribue au dernier bloc un horodatage dans le futur, qui respecte la règle du NAT + 2 heures. Le protocole en déduit alors que la période a duré bien plus longtemps qu’en réalité, ce qui entraîne une réduction artificielle et injustifiée de la difficulté pour la période suivante.
En répétant ce procédé sur plusieurs périodes successives, un attaquant pourrait théoriquement abaisser la difficulté jusqu’à produire des blocs à un rythme extrême (jusqu’à un maximum de 6 blocs par seconde). Cette décélération puis accélération extrême compromettrait la sécurité des fonds protégés par des timelocks, pourrait saturer la bande passante des nœuds du réseau, faciliterait certains types d’attaques comme les attaques éclipse, et entraînerait de nombreuses réorganisations majeures rendant les confirmations de transactions peu fiables. Pour l’attaquant, le principal bénéfice qu’il peut en tirer est de récupérer les subventions de blocs beaucoup plus rapidement que normalement.
La proposition de soft fork « Consensus Cleanup » (BIP-0054) vise à corriger cette vulnérabilité en imposant que le premier bloc d’une nouvelle période de difficulté porte un horodatage qui ne précède pas de plus de 2 heures celui du dernier bloc de la période précédente. Cette contrainte empêche la manipulation extrême des écarts temporels entre deux périodes de retarget et empêche donc cette attaque.
Notons que cette attaque est rendue possible par un bug historique (off-by-one) introduit par Satoshi Nakamoto dans le calcul de l’ajustement de la difficulté. Ce calcul prend pour base une durée de 2 semaines (censée correspondre à \(2016 \times 10\) minutes), et la compare à la différence entre le premier et le dernier bloc de la période, afin de déterminer un écart. Le problème, c’est qu’entre le premier et le dernier bloc d’une période, il n’existe en réalité que 2015 intervalles, et non 2016. Pour que le calcul soit correct, il aurait fallu comparer avec la différence entre le dernier bloc de la période précédente et le dernier bloc de la période actuelle qui vient de se terminer, ce qui aurait bien donné 2016 intervalles. Outre le fait que ce bug biaise très légèrement le calcul d’ajustement d’environ 0,05 %, il est surtout ce qui rend possible les attaques de type time warp. En effet, si la comparaison portait sur le dernier bloc de la période précédente plutôt que sur le premier bloc de la période qui vient de se terminer, il y aurait un chevauchement des périodes, ce qui empêcherait ce type de manipulation. Le problème, c’est que pour corriger réellement ce bug historique, il faudrait faire un hard fork.