Abstract: We analyse one of Bitcoin’s security vulnerabilities, the so-called timewarp attack. This attack would allow a majority of hostile miners to manipulate the block timestamps and arbitrarily bring the difficulty down and mine a block every few seconds. This weakness, first identified in around 2011, could be fixed by the “Great Consensus Cleanup softfork”. We look at the proposed fix in some detail.
Overview
On 26th March 2025, Bitcoin developer Antoine Poinsot published a new Bitcoin Improvement Proposal. It is a softfork proposal known as “The Great Consensus Cleanup”. The upgrade fixes several bugs and vulnerabilities that have been stuck in the Bitcoin protocol for many years. One such bug is the duplicate transaction issue, which we talked about in our recent piece. Another bug that the cleanup softfork would fix, a far more serious one, is called the “timewarp attack” and that is the subject of this piece.
Bitcoin’s Block Timestamp Protection rules
Before we go into the Timewarp attack, let’s remind ourselves of the current time manipulation protection rules:
- Median Past Time (MPT) Rule – The timestamp must be further forwards than the median of the last eleven blocks.
- Future Block Time Rule – The timestamp cannot be more than 2 hours in the future based on the MAX_FUTURE_BLOCK_TIME constant, relative to the median time from the node’s peers. The maximum allowed gap between the time provided by the nodes and the local system clock is 90 minutes, another safeguard.
The MTP rule is designed to make sure the blocks do not go too far in the past and the future block rule prevents them going into the future. Please note that a similar rule to the future block rule cannot be implemented to prevent blocks having a timestamp in the past, as this may impact the initial Blockchain synchronisation. The Timewarp attack involves fake timestamps, with timestamps far back in the past.
Satoshi’s “Off By One” Error
In Bitcoin, a difficulty adjustment period consists of 2016 blocks and with a 10 minute block target this is a period of approximately two weeks. To calculate the mining difficulty adjustment, the protocol calculates the difference in the timestamp between the first and last block in the relevant 2016 block window. This window of 2016 blocks contains 2015 intervals between the 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 error to make, Satoshi seems to have confused blocks with the intervals between the blocks.
Original Satoshi Code
const unsigned int nTargetTimespan = 14 * 24 * 60 * 60; // two weeksSource: https://sourceforge.net/p/bitcoin/code/1/tree//trunk/main.cpp#l687
This error means the target time is 0.05% longer than it should be. Therefore, the Bitcoin target interval time isn’t really 10 minutes, it’s actually 10 minutes and 0.3 seconds. Not that this bug is significant, actually since Bitcoin launched, the average interval has been 9 minutes and 36 seconds, significantly less than 10 minutes. This is because on average since 2009 the hashrate has been increasing. This is why the last halving happened in April 2024, rather than January 2025. We are ahead of schedule. Anyway, this 0.3 second error by Satoshi is pretty irrelevant in the grand scheme of things. Perhaps one day, many years in the future, when the price and hashrate stop increasing, the bug puts us back on schedule.
While the 0.3 second bug itself isn’t a significant issue, there is an interrelated problem that is a somewhat serious vulnerability. The difficulty calculation is based on the first and last block within each 2016 block window. This is also wrong. 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 appears to be the most logical way to calculate the length of the difficulty adjustment windows, where critically the timespan overlaps the different adjustment windows. If this was done, then 2016 would also be the correct number of intervals for which to calculate the target. Perhaps the reason Satoshi made this error is that he had to worry about the first difficulty adjustment period, which never had a last block in the previous period to work with.
The Timewarp Attack
The Timewarp attack on Bitcoin was first discovered in around 2011 and exploits the errors Satoshi made in the difficulty calculation. To conduct the attack, let’s assume mining is 100% centralised and the miners can set any timestamps the protocol allows. In the attack, for almost all blocks, miners set the timestamp to progress one second compared to the previous block, therefore the blockchain moves forwards in time and the MTP rule is observed. To move forwards in time as slowly as possible, miners could keep the same timestamp for six blocks in a row and then increase the time by one second in the next block and so on. This means the block timestamp would move forwards one second every six blocks.
This attack would mean the blockchain gets further and further behind the real time and the difficulty would increase, making it harder and harder to mine. However, to add to the attack, in the last block in each difficulty adjustment period, the miners set the timestamp to the real world time. This next block, the first block in each difficulty adjustment window is then set back in the past again, to one second ahead of the second last block in the previous difficulty adjustment window. This is still compliant with the MTP rule, since one anomaly doesn’t impact the median of 11 blocks in this case.
When conducting this attack, the difficulty after the first epoch won’t be impacted. However, after the 2nd adjustment period since the attack began, the difficulty will adjust downwards. The miners can then create blocks at an incredibly fast rate and perhaps create a large amount of Bitcoin and then perhaps sell the coins and profit.
Contrived Illustration
Since the difficulty period is 2016 blocks, it can be difficult to illustrate this attack in a diagram. Therefore, we have created the below scenario to try and explain the attack.
- Each difficulty adjustment window has five blocks
- The target interval is 10 minutes
- The MTP rule is based on the last three blocks
- The timestamp for each block is incremented by one minute, with the exception of the last block in each epoch, which uses a real timestamp
Illustrative Timewarp Attack
As the chart above illustrates, there are two curves:
- A curve representing the real time, for the last block in each difficulty adjustment window. This curve gets less steep as the miners find blocks faster and faster, as the difficulty lowers
- A straight line which represents the manipulated timestamps, for the other blocks
Bitcoin Timewarp Attack Calculations
The table below shows how fast miners could manipulate the difficulty downwards using this attack in the most extreme way possible.
|
|
Difficulty adjustment (Downwards) | Cumulative impact (Downwards) | Block interval (Minutes) | Epoch length (days) | Cumulative time (days) |
|
|
None | None | 10.00 | 14.00 | 14.00 |
|
|
2.0x | 2.0x | 10.00 | 14.00 | 28.00 |
|
|
2.5x | 5.0x | 5.00 | 7.00 | 35.00 |
|
|
2.7x | 13.5x | 2.00 | 2.80 | 37.80 |
|
|
2.8x | 37.4x | 0.74 | 1.04 | 38.84 |
|
|
2.8x | 104.7x | 0.27 | 0.37 | 39.21 |
|
|
2.8x | 294.1x | 0.10 | 0.13 | 39.35 |
|
|
2.8x | 826.8x | 0.03 | 0.05 | 39.39 |
|
|
2.8x | 2325.6x | 0.01 | 0.02 | 39.41 |
|
|
2.8x | 6541.3x | 0.00 | 0.01 | 39.42 |
|
|
2.8x | 18398.0x | 0.00 | 0.00 | 39.42 |
Note: The maximum difficulty adjustment allowed by the protocol in any period is 4x, however this is not reached in the above table
The difficulty adjustment downwards in each epoch asymptotes to just over 2.8x. This is because as each epoch gets shorter in time, the rate of difficulty adjustment decreases slow down.
By the 11th epoch in the above table, on the 39th day of the attack, more than 6 blocks per second are produced, 10.9 blocks per second to be precise. At this point the limits on the timestamps to allocated to the blocks come into play in a different way. According to the MTP rule time must move forward every 6 blocks and the lowest time increment is 1 second. Therefore, at this point, based on our understanding, the timestamps starting moving forwards faster than real time and the blockchain clock startes to move forwards towards the real world time, but its still way behind. Despite this, the attack can continue, with the difficulty getting lower and lower until it reaches the minimum allowed value.
Viability Of The Attack
While in theory the attack is devastating, there are some challenges in conducting it. Performing the attack probably requires a majority of the hashrate. If there are honest miners putting in honest timestamps, then the attack becomes harder. The MTP rule and the timestamps from the honest miners may limit how far back the malicious miner timestamps can be. Also, if an honest miner produces the first block in any difficulty adjustment window, the attack won’t work for that period. Another mitigating factor, which could make the attack harder to execute, is that it will be visible to everyone. Timestamps, that anyone can see, will have to be manipulated for four weeks before the difficulty adjust downwards, potentially giving us time for an emergency softfork fix to be rolled out.
Solution
Fixing this vulnerability is relatively simple, although it probably requires a softfork protocol change. Directly fixing the issue, by changing the difficulty adjustment algorithm to calculate the timespan between blocks in different 2016 windows and fully fixing the off by one error, is quite complicated. This would also probably be a hardfork. Another fix would be to get rid of the MTP rule and instead require that the time always moves forward every block, although this could mean time could get stuck too far forwards and also means miners could get in trouble for using the real time on their system clocks, which could have an invalid time if another miner’s clock was ahead by a few seconds.
Fortunately, there is a much more simple solution. To prevent the timewarp attack, all we need to do is require the first block in a new difficulty period to have a time no earlier than a certain number of minutes before the last block in the previous period. The number of minutes for this new limit rule has been debated, with proposals ranging from 10 minutes to two hours. Either would probably be fine in terms of mitigating the timewarp attack.
In Poinsot’s Great Consensus Cleanup proposal, he has now settled on 2 hours. 2 hours is just around 0.6% of the difficulty adjustment period target time, therefore the ability to manipulate the difficulty downwards is severely restrained. We have summarised the debate about the grace period that should be used, in the table below:
|
10 minute limit |
2 hour limit |
|
|
Positives |
|
|
|
Negatives |
|
|
The effect of the manipulation to build up exponentially over the time feels like a significant potential weakness. Even though it could take a while, miners could still eventually produce blocks very quickly. Although the rate of growth would be quite slow, perhaps around a 75% downward adjustment per four year halvening or 15% per annum. Controlling the hashrate for long periods like this is challenging and if this happens, maybe Bitcoin has other larger problems anyway. As far as we can tell, just one well placed block with a correct timestamp could undo years worth of manipulation. Therefore, total control is necessary to get this 15% annual growth.
However, in our view, if we have to have another complicated rule, alongside the MTP rule, to fix the timewarp problem, it may be worth a more complete fix. If we are going to go to the trouble of fixing the issue, we might as well try to completely prevent miners from being able to produce blocks fast, even over the ultra long term. We do not want miners thinking that 15% annual growth is baked into the protocol. Therefore, assuming we are correct in our understanding that the 0.6% downward difficulty adjustment can apply for each period and exponentially accumulate, we support a 10 minute rule.
