Satoshi s'est trompé.
Il y a un bug dans le minage de Bitcoin depuis le tout premier jour. C'est une simple erreur de calcul de Satoshi qui pourrait être exploitée pour miner des blocs à une vitesse délirante. C'est un des bugs que le BIP-0054 (en discussion) résout. Je vous explique.
Pour comprendre, il faut d'abord rappeler le fonctionnement du mécanisme d'ajustement de la difficulté. Comme vous le savez, tous les 2016 blocs, soit environ toutes les 2 semaines, les noeuds recalculent la cible de difficulté. L'objectif est de maintenir un rythme stable d'un bloc toutes les 10 minutes, quelle que soit la puissance de calcul déployée par les mineurs. Pour faire cet ajustement, les noeuds mesurent combien de temps la dernière période a duré, la comparent au temps qu'elle aurait due durer (2016 x 600 = 1 209 600 secondes), puis corrigent la difficulté en conséquence.
C'est dans ce calcul qu'il y a le bug. Pour mesurer le temps de la dernière période qui vient de passer, le noeud compare l'horodatage du premier bloc de la période à celui du dernier. Instinctivement, ça parait logique de faire ça, mais en fait c'est une erreur, car il n'y a que 2015 intervalles entre le premier bloc et le dernier de la période, pas 2016.
Si on note t0 l'horodatage du premier bloc et t2015 celui du dernier, le noeud calcule le temps écoulé comme T = t2015 - t0. Les intervalles mesurés sont donc :
de t0 à t1 (1 intervalle) > de t1 à t2 (2 intervalles) > ... > de t2014 à t2015 (2015 intervalles)
On obtient bien 2015 intervalles et pas 2016. Pour en avoir 2016, il aurait fallu calculer T = t2015 - t-1, où t-1 est l'horodatage du dernier bloc de la période précédente. C'est ce qu'on appelle un bug "off-by-one" : une erreur de décalage d'une unité.
Concrètement, l'impact sur la PoW est négligeable. Ce décalage introduit un biais d'environ 0,05% vers une difficulté très légèrement surestimée. Mais le vrai problème est ailleurs. Ce bug fait que les périodes d'ajustement ne se chevauchent pas. L'horodatage du dernier bloc d'une période n'entre pas dans le calcul de la suivante :
- La première période : t0 à t2015
- La deuxième : t2016 à t4031
- etc.
Il n'y a jamais de chevauchement, et c'est précisément cette discontinuité qui rend possible une attaque que le l'on appelle "time warp".
Le principe est le suivant :
1 - un mineur qui controlerait une majorité de la puissance de calcul commence par fixer les horodatages de tous les blocs d'une période, sauf le dernier, au minimum autorisé par les règles du protocole (supérieur au MTP, la médiane des 11 derniers blocs), au lieu de mettre l'heure réelle comme horodatage.
2 - sur le dernier bloc de la période, il attribue un horodatage artificiellement avancé dans le futur. La limite maximum pour un horodatage d'un bloc Bitcoin, c'est NAT + 2 heures. Le NAT c'est la médiane des temps réels des nœuds, mais pour simplifier, on peut dire que c'est presque le temps réel. On prend donc ce temps réel et on ajoute 2 heures de largesse dans le futur. Ce temps NAT + 2h, c'est la limite maximum, et l'attaquant va placer cette limite max dans le futur sur le dernier bloc de la période.
3 - la période est terminée, tous les nœuds Bitcoin appliquent l'ajustement de la difficulté. À cause de la manipulation des horodatages de l'attaquant, la période mesurée a duré plus longtemps qu'en réalité. Les noeuds abaissent donc la difficulté de minage pour la période suivante.
4 - l'attaquant reproduit exactement la même manipulation sur la période suivante. Puisque les périodes ne se chevauchent pas, et puisque le MTP est une médiane et non une moyenne, le premier bloc de la deuxième période d'attaque peut avoir un horodatage loin dans le passé, alors que le précédent a un horodatage dans le futur. À la fin, l'écart entre le premier bloc de la période et le dernier sera encore plus grand que la période précédente, et cet écart augmente de période en période.
En répétant ce procédé sur plusieurs périodes, un attaquant pourrait théoriquement faire chuter la difficulté de minage au point de produire jusqu'à 6 blocs par seconde (au lieu de 1 toutes les 10 minutes). Les conséquences seraient terribles : les timelocks ne serviraient plus à rien, le réseau serait saturé, les réorganisations se multiplieraient, et les confirmations de transactions perdraient leur valeur. Le tout permet à l'attaquant de récupérer les récompenses de bloc à un rythme effrené.
Si Satoshi avait fait se chevaucher les périodes, comme nous l'avons vu en intro, cette attaque ne serait pas possible. Ce qui la rend réalisable, c'est que le calcul du temps de la période repose sur le premier bloc de la période, qui peut être placé loin dans le passé, plutôt que sur le dernier bloc de la période précédente, qui dans le cas de cette attaque se trouve placé dans le futur.
Comment résoudre ce bug ?
Et bien le plus simple serait de corriger l'erreur de Satoshi, et de se faire chevaucher les périodes. Mais c'est impossible sans faire un hard fork. Le BIP-0054 (consensus cleanup) propose donc une autre approche par soft fork : imposer 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 rétablit une forme de continuité entre les périodes, empeche la manipulation des écarts temporels, et donc empeche l'attaque time warp.
Le BIP-0054 ne corrige pas que ça, il corrige également d'autres vulnérabilités historiques du protocole.
La méthode la plus simple pour le lire est de télécharger le PDF disponible directement à la racine du dépôt, ou dans les releases avec la version 0.1.
