Vulnerability of Time Warp Attack in Bitcoin Protocol

Bitcoin developer Antoine Poinsot proposed a new improvement proposal on March 26, 2025, aimed at fixing multiple long-standing vulnerabilities and weaknesses in the Bitcoin protocol. This soft fork proposal, known as "Great Consensus Cleanup," not only addresses the duplicate transaction issue we discussed earlier but also presents a solution for a more serious vulnerability — the "time distortion attack."

Bitcoin Block Timestamp Protection Mechanism

Before discussing time distortion attacks, we need to understand the time manipulation protection rules in the current Bitcoin protocol:

1. Median past time ( MPT ) rule: The block timestamp must be later than the median time of the previous 11 blocks.

2. Future block time rules: The block timestamp cannot exceed 2 hours beyond the median time of the node peers, and the maximum allowable discrepancy between the node time and the local system clock is 90 minutes.

The purpose of these rules is to prevent block timestamps from deviating too much from the actual time, but due to the need to consider the initial blockchain synchronization, it is not possible to completely prohibit past timestamps.

Satoshi Nakamoto's Calculation Error

The difficulty adjustment period of Bitcoin includes 2016 blocks, which theoretically takes about two weeks. However, when calculating the mining difficulty adjustment, the protocol uses a somewhat inaccurate method. It calculates the timestamp difference between the first and last blocks in the 2016 block window, but it should actually calculate the interval between 2015 blocks. This results in the target time being 0.05% longer than it should be, making the actual target interval of Bitcoin 10 minutes and 0.3 seconds, rather than the precise 10 minutes.

This small error is not significant in actual operation, as the average block interval has been less than 10 minutes since the birth of Bitcoin, mainly due to the continuous growth of computing power.

The Principle of Time Warp Attacks

Time warp attacks exploit this flaw in Satoshi Nakamoto's difficulty calculation. An attacker can manipulate block timestamps to gradually cause the blockchain time to fall behind the real time while still complying with protocol rules. Specifically, the attacker will:

1. For most blocks, set the timestamp to be just 1 second later than the previous block.
2. The timestamp is advanced by 1 second every six blocks to comply with the MPT rules.
3. Set the timestamp to the real-world time at the last block of each difficulty adjustment period.
4. The timestamp of the first block in the new difficulty adjustment period has returned to the past, being 1 second later than the penultimate block of the previous period.

This operation will cause the difficulty to start decreasing after the second adjustment period, allowing attackers to create blocks at a very fast rate and acquire a large amount of Bitcoin.

Impact and Feasibility of Attacks

In theory, this type of attack could have serious consequences, but it faces many challenges in implementation.

1. Need to control most of the network's computing power.
2. The presence of honest miners will increase the difficulty of attacks.
3. The attack process is publicly visible and may trigger an emergency fix.
4. It takes four weeks to achieve a difficulty adjustment, allowing time to respond.

Solution

To fix this vulnerability, Poinsot's proposal suggests that at the beginning of each new difficulty adjustment period, the timestamp of the first block should not be earlier than 2 hours after the timestamp of the last block of the previous period. This simple rule can effectively limit the extent to which difficulty can be manipulated downwards, while maintaining enough flexibility to accommodate normal network fluctuations.

This repair solution is simpler and more conservative compared to other possible solutions (such as completely modifying the difficulty adjustment algorithm or removing the MTP rule), effectively preventing time-warp attacks while minimizing the risk of unexpected invalid blocks.