Timewarp Attack est une manipulation coordonnée des horodatages des en-têtes qui fausse le calcul de la difficulté suivante. L’attaque peut l’abaisser sans baisse correspondante du hashrate et accélérer ainsi la production de blocs.
Bitcoin recalcule la difficulté tous les 2016 blocs et vise un intervalle moyen de 10 minutes. Il soustrait l’heure du premier bloc de la période à celle du dernier : seuls 2015 intervalles sont donc mesurés. L’intervalle entre le dernier bloc d’une période et le premier de la suivante échappe à ces différences. À cette frontière, l’heure peut reculer sans que les deux calculs relient les périodes de façon continue. [4] [3]
L’heure d’un nouveau bloc doit dépasser Median Time Past (MTP), la médiane des heures des 11 blocs précédents. Elle ne doit pas forcément dépasser celle du bloc immédiatement précédent. Les attaquants peuvent placer presque toutes les heures seulement 1 seconde après MTP, donner au dernier bloc de la période l’heure réelle approximative, puis revenir à une heure ancienne. Ils manipulent les nouveaux blocs, sans réécrire les en-têtes déjà confirmés. [1]
Le scénario classique suppose une majorité du hashrate, ou une minorité disposant d’une influence supplémentaire sur l’ordre des blocs, par exemple grâce au Selfish Mining. Il faut maîtriser durablement la série temporelle, pas simplement produire un bloc à l’heure inhabituelle. Le démarrage demande environ un mois de préparation dont les traces sont visibles publiquement dans la chaîne. [1]
Dans la deuxième période attaquée, les heures peuvent suggérer une moyenne de 20 minutes par bloc et diviser approximativement la difficulté par deux. La période suivante est minée plus vite, mais les heures manipulées appellent une nouvelle baisse. La limite d’un facteur quatre par ajustement n’empêche pas les répétitions. La limite théorique à long terme liée à MTP correspond à environ 6 blocs par seconde ; ce n’est pas une promesse de débit pratique du réseau. [1] [3]
Des blocs plus rapides concentreraient les subventions futures sur une durée plus courte ; ils ne relèvent pas à eux seuls la limite de 21 millions de BTC. Les nœuds devraient vérifier et relayer les données plus vite. Processeurs saturés, connexions insuffisantes, branches concurrentes et réorganisations fréquentes rendraient les confirmations moins fiables. [1]
BIP 113 utilise le MTP du bloc précédent pour évaluer les verrouillages absolus nLockTime exprimés en heure. Ceux exprimés en hauteur de bloc restent fondés sur la hauteur. Pendant l’attaque, MTP peut progresser bien plus lentement que les horloges réelles. Des fonds soumis à une condition temporelle pourraient rester indisponibles plus longtemps que prévu, et des protocoles complexes perdre la coordination entre leurs étapes. [5] [1]
La proposition limite l’heure du premier bloc d’une période : elle ne peut précéder celle du bloc précédent de plus de 7200 secondes, soit deux heures. L’heure du dernier bloc doit aussi être au moins égale à celle du premier. La spécification a le statut Complete. Cela signifie que la proposition est achevée, pas activée : imposer de nouvelles règles de consensus sur mainnet nécessite une activation distincte. [2]
Comparez les heures des en-têtes, MTP, les frontières tous les 2016 blocs, le rythme réel, la difficulté et le hashrate. Distinguez l’attaque classique de la variante Murch–Zawy et les règles de testnet de celles de mainnet. Le logiciel peut préparer des modèles de blocs plus sûrs ; cela ne signifie pas que tout le réseau rejette chaque bloc contraire à la protection proposée. [3] [2]
Pour une vision complète, lisez aussi Difficulty Adjustment, Minage, Proof of Work, Consensus Cleanup, Timelock, Reorg. Cette entrée est également citée par Consensus Cleanup.
01L’attaque nécessite-t-elle une majorité du hashrate ?+
Le scénario classique suppose une majorité ou un autre avantage permettant d’influencer suffisamment l’ordre des blocs. Un petit mineur sans cet avantage ne maîtrise pas assez leurs heures.
02Median Time Past suffit-il à protéger le réseau ?+
Non. MTP contraint chaque horodatage, mais ne ferme pas la faille entre périodes. BIP 54 propose des contraintes supplémentaires sur la relation entre les heures du premier et du dernier bloc.