# What is time warp attack and how does it work in general?

I am trying to understand the recent time warp attack on verge but since the attack is universal across all POW block chain i figure I could also ask here since people here are .. more knowledgeable.

I don't understand the detail of code.

But i assume something like, in bitcoin, there is a difficulty parameter that is decided for every 2016 blocks. Perhaps a integer. Such that all 2016 blocks mined during that that period all needs to have a hash that is less than that integer.

This difficulty is recalculated whenever 2016 blocks are mined. Everybody goes over this entire 2016 blocks, and take the earliest time stamp, take the latest timestamp, calculate how long it took to mine those blocks, and decide on a new difficulty integer for the next 2016 blocks.

But how does time warp works? I read something along, miners starts submitting blocks with large drifting timestamps (i think it is 2hrs for bitcoin?), but 2 hours is relatively small compare to the average time it is going to mine 2016 blocks (300+hrs). How would add or subtract 2 hours in the blocks cause mining to difficulty to decrease dramatically?

For a miner to drastically decrease difficulty, wouldn't he need:

1. Majority hash power so he can construct all 2016 blocks.

2. Change all timestamp in this 2016 blocks in a way such that it causes dramatically decreased difficulty

3. profit... (but by that time people probably abandoned the chain anyway)

But once we get to point #1 we are.. kind of in trouble already, it's just that having time warp made it worse???

Thanks!

The Bitcoin Protocol (consensus rules) has two relevant rules for the timestamps in block headers:

1. A node will not accept a block whose timestamp is more than two hours in the future.
2. A node will not accept a block unless it has a timestamp greater than the median of the previous 11 blocks. In Bitcoin, we call this Median-Time-Past (MTP).

As you mention in your question, difficulty changes are calculated based on the times of the first and last blocks in a 2,016-block difficulty period.

Given the above rules, if all miners agreed, they could simply increment the clock the minimum amount of one second MTP for the first 2,015 blocks and then set the time to two hours in the future. That would basically give them just a small decrease in the difficulty, but think about what happens to the MTP when they add that last slightly-future datapoint: the actual median doesn't change much at all. Actual time stamps are in seconds, but here's a set of 11 timestamps in days delta from present time:

``````[-13, -13, -13, -13, -13, -13, -13, -13, -13, -13, 0]
``````

The median of the above is -13, meaning that after miners create the slightly-future-time block at the end of the difficulty period, they don't need to move their timestamps forward more than the minimum one second---so the next difficulty period starts out -13 days.

At the end of the next difficulty period, miners again move the timestamp forward as far as possible, so the protocol thinks it took 28 days to mine the blocks---half the expected speed---and so decreases the difficulty by about half. Now the values used for MTP look like:

``````[-27, -27, -27, -27, -27, -27, -27, -27, -27, -27, 0]
``````

So miners can continue keeping timestamps far in the past and repeat the attack, lowering difficulty every period until the point where it takes them less than 2,016 seconds to produce 2,016 blocks, at which point they can't lower difficulty any further because the MTP function requires time increase by a minimum of one second over the median every block.

Now, your main question was how can this attack work without collusion by a majority of miners. Now that you've seen how the attack works with all miners participating, it should be clear than selecting the median time can allow an attacking miner who's lucky enough to find blocks reliably to prevent median time from jumping forward to an honest value. For example, imagine these are the times of the previous 11 blocks, in block chain sequence:

``````[-27, 0, -27, 0, -27, 0, -27, 0, -27, 0, -27]
``````

If you sort those numbers to find the median, it's -27 even though 5/11ths (45%) of the hashrate is mining accurately. But wait, doesn't that mean the attacking miner has 55% of the hashrate? Maybe not, for a large miner with about 30% or more of the hashrate could obtain an advantage over other miners using a selfish mining attack, or the miner could simply threaten to attempt to make stale ("orphan") other miners blocks who have accurate time stamps, causing those honest miners to earn less income.

I myself don't consider the attack particularly likely on Bitcoin because it's slow to execute and publicly obvious, but it's something protocol designers do need to keep in mind for when they change parameters, as those changes could make the attack easier to execute.

• re: "it's something protocol designers do need to keep in mind for when they change parameters": a perfect example of this is the recent attack against Verge (XVG), where a different algorithmic setup allowed a timewarp attack to be more potent. David has another great answer on this here: bitcoin.stackexchange.com/questions/75438/… Jun 2, 2018 at 20:30
• It seems wrong for a node to accept: [-13, -13, -13, -13, -13, -13, -13, -13, -13, -13, 0] ? Isn't the last block "more than 2 hours in the future" from the previous block ? It seem it's 13*24=312 hours in the future. The protocol's notion of time comes from the timestamps of the blocks and the time reported by peer nodes. Oct 3, 2018 at 10:38
• @dbkeys by "2 hours in the future", I mean by the node's own clock (e.g. its host system's clock). For example, it's 2018-10-03 11:00 UTC as I write this; my node will accept any otherwise-valid block right now with as timestamp up to 2018-10-03 13:00, but will not currently accept an otherwise-valid block with a timestamp of 13:01. If we wait a minute, then my node would accept the 13:01 block. Oct 3, 2018 at 11:03
• "they could simply increment the clock the minimum amount of one second MTP for the first 2,015 blocks..." It's not clear to me what exactly is going on. What clock is being incremented 1 second, (is it the system clock, or the timestamps ) ? how many times is it being incremented one second ? Oct 4, 2018 at 10:10
• "Technically there's an off-by-one error there, but that's not important here." -> I think it's important. If the difficulty re-target were overlapping (as they would if it was based on the last 2016 blocks instead of 2015), the timewarp attack wouldn't be possible. Of course miners could still hold off timestamps in the past but it would be much less effective. Jan 8 at 10:23

A time warp attack occurs when a miner manages to put an incorrect time-stamp into the blocks in order to reduce the subsequent mining difficulty.

By inserting wrong time-stamps a miner, or a group of miners with majority of the hash rate can deceive the difficulty adjustment algorithm (DAA) that deals with adjusting mining difficulty, thereby pushing it to lower it's value, causing extraction of the blocks to become faster and therefore make mining more profitable.

As per the consensus rule, Bitcoin won't accept a block with a time-stamp more than 2 hours in the future, and it won't accept a block unless its time-stamp is greater than the median time-past (MTP) of the previous 11 blocks.

A miner can exploit this consensus rule to mine block in a difficulty adjustment period of 2,016 blocks by incrementing the timestamps of the blocks mined by merely 1 second greater than the MTP of the past 11 blocks for 2,015 blocks and then insert the time stamp as current time + 2hours.

This will not bring any drastic effect in the first time epoch. However, for the subsequent difficulty adjustment period, the miner can manipulate the time stamp of the first block (block 2,017) and set it to be 1 second greater than the MTP (block 2,011). This will deceive the DAA into believing that the first block of the second difficulty adjustment period (2,017) was mined ~13 days ago, and then insert the timestamp of time final block of the second difficulty adjustment period to be current time + 2hours, and thus it would appear that it took ~28 days to mine 2,016 blocks in the second difficulty adjustment period, which will lead to a decrease in the difficulty of ~50%. It is important to note that DAA takes into consideration the timestamps of the first and the last blocks in a difficulty adjustment period to adjust difficulty.

The time-stamp for the first block in the second difficulty adjustment period(block 2,017) should be minimum 1 second greater than the timestamp of the median of the previous 11 blocks(block 2,011)i.e 6th previous block, which is ~13 days in the past, while the time stamp of the last block of the second difficulty adjustment period is C+2 (Current time + 2hours), thus deceiving DAA to believe that it took ~28 days for all the blocks in the second difficulty adjustment period.

New contributor
Faisal Qureshi is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.