Bitcoin security vulnerability: Time warp attack

Overview

On March 26, 2025, Bitcoin developer Antoine Poinsot released a new Bitcoin Improvement Proposal . This is a soft fork proposal called the "Grand Consensus Cleanup". The upgrade fixes several vulnerabilities and weaknesses that have existed in the Bitcoin protocol for many years. One of these vulnerabilities is the duplicate transaction problem that we recently discussed. Another more serious vulnerability that will be fixed by the cleanup soft fork is called the "time warp attack", which is the topic of this article.

Bitcoin block timestamp protection rules

Before discussing time warp attacks, let's review the current rules for time manipulation protection:

Median Past Time (MPT) rule — The timestamp must be later than the median time of the last eleven blocks.

Future block time rules — Based on the MAX_FUTURE_BLOCK_TIME constant, the timestamp cannot be more than 2 hours ahead of the median time of the node's peers. The maximum difference allowed between the time provided by the node and the local system clock is 90 minutes, which is another safety guarantee.

The MPT rule is designed to ensure that blocks do not go too far into the past, while the future block rule prevents them from going into the future. Note that a rule similar to the future block rule cannot be implemented to prevent blocks from having timestamps in the past, as this could affect the initial blockchain synchronization. A time warp attack involves forging timestamps that go too far into the past.

Satoshi Nakamoto's "off by one" error

In Bitcoin, a difficulty adjustment period consists of 2016 blocks, which is about two weeks with a 10-minute block target. To calculate the mining difficulty adjustment , the protocol calculates the difference in timestamps between the first and last block in the relevant 2016-block window. This 2016-block window contains the intervals between 2015 blocks (i.e. 2016 minus one). Therefore, the relevant target time used should be 60 seconds * 10 minutes * 2015 intervals, which equals 1,209,000 seconds. However, the Bitcoin protocol uses the number 2016 to calculate the target. 60 seconds * 10 minutes * 2016 = 1,209,600 seconds. This is an off-by-one error. This is an easy mistake to make, and Satoshi seems to have confused blocks with the intervals between blocks.

Original Satoshi Code

 Source: https://sourceforge.net/p/bitcoin/code/1/tree//trunk/main.cpp#l687

This bug meant that the target time was 0.05% longer than it should have been. So instead of the Bitcoin target interval being 10 minutes, it was 10 minutes and 0.3 seconds. This bug is not important, in fact since Bitcoin launched, the average interval has been 9 minutes and 36 seconds, significantly less than 10 minutes. This is because the average hashrate has been increasing since 2009. This is why the last halving happened in April 2024, not January 2025. We were ahead of schedule. In any case, Satoshi's 0.3 second mistake is fairly insignificant in the overall picture. Maybe one day, in the distant future, when the price and hashrate stop growing, this bug will get us back on track.

While the 0.3 second bug itself is not a significant issue, there is a related issue that is a more serious bug. The difficulty calculation is based on the first and last block within each 2016 block window. This is also wrong. In our opinion, the relevant period should be the difference between the last block of the previous 2016 block window and the last block of the current window. This seems to be the most reasonable way to calculate the length of the difficulty adjustment window, where the key is that the timespan covers different adjustment windows. If this is done, then 2016 will also be the correct number of intervals to calculate the target. Perhaps the reason why Satoshi made this mistake is that he had to consider the first difficulty adjustment cycle, which never had the last block of the previous cycle available.

Time Warp Attack

The time warp attack on Bitcoin was first discovered around 2011 and exploits a mistake made by Satoshi Nakamoto in the difficulty calculation. To perform the attack, assume that mining is 100% centralized and miners can set any timestamp allowed by the protocol. In the attack, for almost all blocks, miners set the timestamp to be one second ahead of the previous block, so the blockchain moves forward in time and obeys the MTP rule. To move time forward as slowly as possible, miners can keep the same timestamp for six consecutive blocks, then increase the time by one second in the next block, and so on. This means that the block timestamp moves forward by one second every six blocks.

This attack means that the blockchain will fall further and further behind real time, and the difficulty will increase, making mining increasingly difficult. However, to enhance the attack, in the last block of each difficulty adjustment period, miners set the timestamp to real world time. The next block, the first block of each difficulty adjustment window, is then set back in time, one second ahead of the second-to-last block of the previous difficulty adjustment window. This still complies with the MTP rule, because in this case, one anomaly will not affect the median of 11 blocks.

When this attack is performed, the difficulty will not be affected after the first cycle. However, after the second adjustment cycle after the attack begins, the difficulty will adjust downward. Miners can then create blocks at an extremely fast rate, potentially creating a large number of Bitcoins, which can then be sold at a profit.

Simplified description

Since the difficulty cycle is 2016 blocks, illustrating this attack in a diagram may be difficult. Therefore, we created the following scenario to try to explain this attack.

• Each difficulty adjustment window has five blocks
• Target intervals are 10 minutes
• MTP rules are based on the last three blocks
• The timestamp of each block increases by one minute, except for the last block of each cycle, which uses the real timestamp.

Illustrative Time Warp Attack

As shown in the figure above, there are two curves:

• A curve representing the real time of the last block in each difficulty adjustment window. As miners find blocks faster and faster, the difficulty decreases and this curve becomes less steep.
• Lines representing timestamps of other block manipulations

Bitcoin time warp attack calculation

The chart below shows how miners could use this attack in its most extreme form to manipulate difficulty downward.

Note: The maximum difficulty adjustment allowed by the protocol for any period is 4x, but this value has not been reached in the table above

The difficulty adjusts downwards asymptotically to just over 2.8x per epoch. This is because as each epoch gets shorter in time, the rate at which the difficulty adjustment slows down decreases.

In the 11th cycle in the table above, on the 39th day of the attack, more than 6 blocks are produced per second, 10.9 blocks per second to be exact. At this point, the timestamp limit assigned to the blocks comes into play in a different way. According to the MTP rule, time must move forward every 6 blocks, and the smallest time increment is 1 second. Therefore, at this point, based on our understanding, timestamps start to advance faster than real time, and the blockchain clock starts to move forward, close to real world time, but still far behind. Despite this, the attack can continue, and the difficulty keeps decreasing until it reaches the minimum allowed.

Attack Feasibility

While in theory this attack is devastating, there are some challenges in implementing it. Executing the attack would likely require a large portion of the hashrate. If there are honest miners inputting honest timestamps, then the attack becomes much more difficult. The MTP rule and the timestamps of honest miners may limit how far back a malicious miner's timestamps can go. Additionally, if an honest miner produces the first block of any difficulty adjustment window, the attack will not work for that period. Another mitigating factor that may make the attack harder to execute is that it is visible to everyone. Anyone can see the timestamps, and having to manipulate the timestamps for four weeks before the difficulty adjusts downward may give us time to push out an emergency soft fork fix.

Solution

Fixing this vulnerability is relatively simple, although it may require a soft fork protocol change. It is quite complex to fix this directly by changing the difficulty adjustment algorithm to calculate the time span between blocks in different 2016 windows and completely fix the difference-by-one bug. This may also be a hard fork. Another fix would be to do away with the MTP rule and instead require that time always moves forward in each block, although this may mean that time can get stuck too far ahead and also means that miners may get into trouble for using real time on their system clocks, which may have invalid times if another miner's clock is a few seconds ahead.

Fortunately, there is a simpler solution. To prevent timewarp attacks, we simply need to require that the first block of a new difficulty period be no earlier than a certain number of minutes before the last block of the previous period. The number of minutes for this new limit has been discussed, with proposals ranging from 10 minutes to 2 hours. Both are probably fine in terms of mitigating timewarp attacks.

In Poinsot's Grand Consensus Cleanup proposal, he now settles on 2 hours . 2 hours is only about 0.6% of the target time for the difficulty adjustment cycle, so the ability to manipulate difficulty downward is severely limited. We summarize the discussion about the grace period that should be used in the following table: