Overview

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

Bitcoin Block Timestamp Protection Rules

Before discussing the time warp attack, let's review the current timestamp manipulation protection rules:

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

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

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

Satoshi's "Off by One" Error

In Bitcoin, a difficulty adjustment period consists of 2016 blocks, calculated with a 10-minute block target, which is approximately two weeks. To calculate the mining difficulty adjustment, the protocol calculates the timestamp difference between the first and last blocks in the relevant 2016 block window. This 2016 block window includes 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. It is an easy mistake to make, and Satoshi seems to have confused the intervals between blocks.

Original Satoshi Code

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

This error means that the target time is 0.05% longer than it should be. Therefore, the actual Bitcoin target interval time is not 10 minutes, but 10 minutes and 0.3 seconds. This vulnerability is not significant; in fact, since Bitcoin's inception, the average interval has been 9 minutes and 36 seconds, clearly less than 10 minutes. This is because the average hash rate has been increasing since 2009. This is why the last halving occurred in April 2024, rather than January 2025. We are ahead of schedule. In any case, Satoshi's 0.3-second error is relatively inconsequential overall. Perhaps one day, in the distant future, when prices and hash rates stop growing, this vulnerability will bring us back on schedule.

While the 0.3-second vulnerability itself is not a major issue, there is a related problem, which is a more serious vulnerability. The difficulty calculation is based on the first and last blocks within each 2016 block window. This is also incorrect. In our view, 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 time span covers different adjustment windows. If this were done, then 2016 would also be the correct number of intervals for calculating the target. Perhaps the reason Satoshi made this mistake is that he had to consider the first difficulty adjustment period, which never had the last block of the previous period available.

Time Warp Attack

The Bitcoin time warp attack was first discovered around 2011, exploiting the error Satoshi made in the difficulty calculation. To carry out the attack, assume 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, thus moving the blockchain forward in time while adhering to the MTP rule. To move time forward as slowly as possible, miners can keep the same timestamp for six consecutive blocks and 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 increasingly lag behind real time, making mining more difficult as the difficulty increases. However, to enhance the attack's effect, in the last block of each difficulty adjustment period, miners set the timestamp to the real-world time. The next block, which is the first block of each difficulty adjustment window, is then set back to the past, 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, an anomaly will not affect the median of 11 blocks.

When this attack is carried out, the difficulty after the first period will not be affected. However, after the second adjustment period following the start of the attack, the difficulty will adjust downward. Miners can then create blocks at an extremely fast rate, potentially generating a large amount of Bitcoin and then selling these coins for profit.

Simplified Explanation

Since the difficulty period consists of 2016 blocks, illustrating this attack in a chart may be challenging. Therefore, we created the following scenario to try to explain this attack.

• Each difficulty adjustment window has five blocks
• The target interval is 10 minutes
• The MTP rule is based on the last three blocks
• Each block's timestamp increases by one minute, except for the last block of each period, which uses the real timestamp

Illustrative Time Warp Attack

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

• The curve representing the real time of the last block of each difficulty adjustment window. As miners find blocks faster, the difficulty decreases, making this curve less steep.
• The straight line representing the manipulation of timestamps of other blocks.

Bitcoin Time Warp Attack Calculation

The table below shows how miners can use this attack in the most extreme way to manipulate the difficulty downward.

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

The difficulty adjustment for each period approaches slightly above 2.8 times downward. This is because as each period becomes shorter in time, the rate of slowdown in difficulty adjustment decreases.

In the 11th period of the table, on the 39th day of the attack, more than 6 blocks are produced per second, specifically 10.9 blocks per second. At this point, the time limit assigned to the blocks' timestamps plays a role in a different way. According to the MTP rule, time must move forward every 6 blocks, with the minimum time increment being 1 second. Therefore, at this point, based on our understanding, timestamps begin to advance faster than real time, and the blockchain clock starts to move forward, approaching real-world time, but still lagging far behind. Nevertheless, the attack can continue, and the difficulty continues to decrease until it reaches the allowed minimum.

Attack Feasibility

While this attack is theoretically devastating, there are some challenges in implementing it. Executing the attack may require a majority of the hash rate. If there are honest miners inputting honest timestamps, the attack becomes more difficult. The MTP rule and timestamps from honest miners may limit how far back malicious miners can manipulate timestamps. Additionally, if an honest miner produces the first block of any difficulty adjustment window, the attack for that period will not work. Another factor that may make the attack harder to execute is that it is visible to everyone. Anyone can see the timestamps, and the timestamps must be manipulated around before the difficulty adjusts downward, potentially giving us time to launch an emergency soft fork fix.

Solution

Fixing this vulnerability is relatively simple, although it may require a soft fork protocol change. Directly fixing this issue by changing the difficulty adjustment algorithm to calculate the time span between blocks in different 2016 windows and completely fixing the off by one error is quite complex. This could also be a hard fork. Another method of fixing it is to eliminate the MTP rule and instead require that time always moves forward in each block, although this could mean that time might get stuck too far ahead, and it could also mean that miners might run into trouble using real time on their system clocks if another miner's clock is ahead by a few seconds, potentially leading to invalid timestamps.

Fortunately, there is a simpler solution. To prevent time warp attacks, we only need to require that the timestamp of the first block of the new difficulty period is not earlier than a specific number of minutes before the last block of the previous period. The number of minutes for this new limit rule has been discussed, with proposals ranging from 10 minutes to 2 hours. In terms of mitigating time warp attacks, both may be viable.

In Poinsot's Big Consensus Cleanup proposal, he now specifies a 2-hour limit. Two hours is only about 0.6% of the target time for the difficulty adjustment period, thus strictly limiting the ability to manipulate the difficulty downward. We summarize the discussion regarding the grace period that should be used in the table below:

10-Minute Limit

Two-Hour Limit

Pros

This has the good characteristic of offsetting the impact of the "off by one" error. If an attack occurs, its impact is exactly countered by Satoshi's mistake. This is a sufficiently long time period to minimize the risk of accidental invalid blocks.

This is a sufficiently long time period to minimize the risk of accidental invalid blocks.
This is the time period chosen by Fabian Jahr when testing this feature for testnet4.
This 2-hour time period aligns with the future block timestamp rule, allowing miners to always correct the maximum allowed future time error in a block.
Compared to the current rule set, this is a more conservative change that may not be as strict as the MTP rule under normal circumstances.
0.6% is a relatively small number. 

Cons

• If miners use real-world clocks to generate timestamps, the risk of invalid blocks increases.
• This rule represents a more significant protocol change, which may be stricter than the MTP rule under normal circumstances, further increasing complexity.

This still allows attacking miners to manipulate the difficulty downward by about 0.6% each cycle, but this would only be a one-time change and cannot compound.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。