Time Warp Attack

Here's the English translation:

Author: BitMEX Research

Source: https://blog.bitmex.com/the-timewarp-attack/

**Abstract**: We analyzed a security vulnerability in Bitcoin called the "Timewarp Attack". This attack allows malicious miners with majority hash power to manipulate block timestamps, thereby arbitrarily lowering block difficulty so that a block can be mined in just a few seconds. This weakness was first discovered around 2011 and can be fixed through a "Consensus Cleanup Soft Fork". We also discuss some details of the proposed fixes. [Rest of the translation follows the same professional and accurate approach, maintaining the technical terminology and nuances of the original text]

Carefully Designed Illustration

Because a difficulty adjustment window is 2016 blocks, it is difficult to demonstrate such an attack in one diagram. Therefore, we designed the following scenario to explain the time warp attack.

• Each difficulty adjustment window has only 5 blocks
• The target block interval is 10 minutes
• MTP rules only consider the past 3 blocks
• The timestamp of each block is only 1 minute more, except for the last block of each window, which uses the real time

- Illustration of Time Warp Attack -

As shown in the diagram, there are two lines:

1. The red curve represents real time, intersecting with the blue histogram line representing block timestamps at the last block of each difficulty adjustment cycle. This curve becomes increasingly flat because miners' block production speed becomes faster (as difficulty decreases).
2. The blue histogram line represents manipulated timestamps.

Calculation of Time Warp Attack

The following diagram shows how quickly miners can reduce mining difficulty using a time warp attack in the most extreme case.

[The table is translated exactly as in the original text, with the same column headers and data]

Note: The maximum difficulty adjustment allowed by the protocol in a single window is 4 times, but the diagram does not reach this.

The difficulty adjustment within a single cycle is slightly higher than 2.8 times. This is because as the duration of each cycle becomes shorter, the difficulty also decreases more slowly.

In the 11th window, which is the 39th day after the attack, more than 6 blocks can be produced in one second, precisely 10.9 blocks. At this point, the role of timestamps assigned to blocks changes. According to the MTP rule, every 6 blocks, the timestamp must move forward, with a minimum increment of 1 second. Therefore, at this point, based on our understanding, the timestamp movement will be faster than real-time movement, and the blockchain clock will start to tend towards the real value but will still lag behind real time. Moreover, the attack can continue until the difficulty is reduced to its lowest possible value.

Significance of the Attack

Although theoretically devastating, executing such an attack faces some difficulties. Carrying out the attack might require controlling the majority of computing power. The attack becomes challenging if honest miners publish honest timestamps. The MTP rule and timestamps from honest miners may limit the extent to which malicious miners can manipulate timestamps. Additionally, if honest miners produce the first block of any difficulty adjustment window, the attack will be ineffective (paused) in that window. Another mitigating factor that increases the attack's difficulty is that such an attack is visible to everyone. Timestamps are visible to all, and manipulating timestamps would require 4 weeks before the difficulty actually drops; we might be able to implement an emergency soft fork to stop it during this period.

Solutions

Fixing this vulnerability is not difficult, though it might require a soft fork protocol change. Changing the difficulty adjustment algorithm, calculating the timestamp difference of another 2016 block interval, and completely fixing the off-by-one error could directly solve the problem but would be very complex and might require a hard fork. Another fix would be to abandon the MTP rule and require each block's timestamp to be greater than the previous block's, though this might mean timestamps could run ahead of real time and disadvantage miners using their own operating system clocks because other miners have advanced their clocks by a few seconds (making their timestamps invalid).

Fortunately, there is a very simple solution. To prevent timestamp attacks, we only need to ensure that the timestamp of the first block in a difficulty adjustment window cannot be too small compared to the last block of the previous window. The specific limit (in minutes) has been under discussion, with proposals ranging from 10 minutes to 2 hours. From the perspective of mitigating the time warp attack, any seems viable.

The current version of Poinsot's Consensus Cleanup proposal decides to use "2 hours". 2 hours is only about 0.6% of the target time for a difficulty adjustment window, so the ability to manipulate difficulty reduction would be greatly limited. We have summarized the discussion about the grace period length:

10 Minutes

Supporting Arguments:

• This value has a very attractive property: it exactly offsets the impact of the off-by-one error. If someone launches an attack, its effect would be exactly neutralized by Satoshi's error.

Opposing Arguments:

• If a miner uses real time to set timestamps, there is an additional risk of creating invalid blocks.
• This rule is a more significant protocol change that might be more strict in regular cases than MTP, adding extra complexity.

2 Hours

Supporting Arguments:

• This grace period is long enough to minimize the risk of accidentally mining invalid blocks.
• This is the value Fabian Jahr chose for testnet4 when testing this proposal.
• This value matches the future block timestamp rules, thus always allowing miners to correct the maximum allowed future time error within a block.
• Compared to the current ruleset, this is a more conservative change that may be more lenient than the regular MTP rules

Opposing opinions:

• This still allows attacking miners to reduce difficulty by about 0.6% in each window; however, this would be a one-time change that cannot be multiplied.

(End)