# How could a time warp attack be prevented?

jarpian explains what a time warp attack (AKA zeitgeist attack) is:

This is a 51% attack where the attacker sets the block timestamps artificially to lower the difficulty, allowing him to profit more coins than his hash rate would warrant. It works because the difficulty adjustment formula is based purely on timestamps that can be chosen quite freely by the attacker. In particular, the timestamps are not required to be in increasing order. ArtForz explains the attack in detail here.

This attack was used against the new Geist Geld block chain. Geist Geld difficulty adjusts every 16 blocks making the chain particularly vulnerable against this attack. An attacker targeting Bitcoin would have to mine a full set of 2016 blocks at the current difficulty before starting to get any benefit compared to a "normal" 51% attack.

Obviously, performing this attack would be horrendously expensive. (Coinometrics places the cost at about \$463 million at time of writing.)

However, if you were successful, you could lower the difficulty and increase the block rate by a factor of 4 every 2 weeks, letting you mint coins more than every 10 minutes.

The obvious way of fixing this - changing the block retarget period from (2016*n, 2016*n + 2015) to (2016*n, 2016*n + 2016) is problematic. Blocks produced by the new implementation would be invalid in the old implementation, and vice-versa. (Source)

So, how could a time warp attack be prevented in a non-disruptive way?

• I find this question valuable and prefer open discussion over fear of fear. If there's any interesting discussion of this elsewhere, please reference it in the answer for posterity. – Chuck Batson Jan 7 '15 at 15:35
• I didn't know there was such thing as non-disruptive time warp? – user24697 Mar 14 '15 at 22:08

## 2 Answers

The simple solution is a soft fork that requires each block's time be equal to or greater than the time of the previous block on the block chain. That is, time on the block chain can't go backwards.

If time can't go backwards, then the attacker can't artificially lower difficulty except by mining blocks with times in the future, and the network already rejects blocks more than 120 minutes into the future.

This proposal is a soft fork because non-upgraded miners will accept a more difficult chain whose times only increase or stay the same. If implemented the same way as BIP34, the supermajority of hash rate would be upgraded before the new rule was applied, minimizing disruption.

• The downside could be avoided by slightly changing the rule: change it to say that timestamps of child blocks must be greater than or equal to the timestamps of their parents. If a node feels that the chain tip's timestamp is too far into the future (but not so far that they'd reject it) then they can set the timestamp of their block to be equal to the timestamp of their parent. Any node that would reject their block as being too far into the future would also reject the parent block. So, the rule wouldn't change that case. – Nick ODell Jan 15 '15 at 6:14
• @NickODell Are you saying that for block chain `A->B->C`, C's time could be >= A's time? That's effectively no different than C's time being == B's time, because any node that rejects B also rejects C. If that's not what you're saying, then maybe I miscommunicated: by `>= the previous block's time`, I meant the previous block on the block chain, specifically the one referred to in the block header field prevHeaderHash. So block A time <= block B time <= block C time. If there's a stale block B′, its time has no bearing on block C time. I'll edit the post to make this clearer. – David A. Harding Jan 15 '15 at 13:30
• Hmm. I guess it's true today that any node that rejects B (for having a too-far future time) also rejects C, so there's no new downside that I can think of. I'll remove that part of my post. – David A. Harding Jan 15 '15 at 13:42

Keep your eyes on networks such as Myriad, Digibyte, Digitalcoin, Unitus and others that use Multi-Algo proof of work. As some of you may know, Myriadcoin was being Timewarp attacked toward the end of last year and has successfully ended the bad actors' efforts. I for one, don't know where the thresholds are for a % of hashrate to be able to pull off such an attack. An in depth analysis of the Myriad Blockchain (timestamps and all, network traffic from the attack would be nice too, but must be captured live) and a look over at https://github.com/myriadcoin/myriadcoin would be a good idea for anyone interested in solving timewarp issues.

• So, what was their solution? – Nick ODell Jan 11 '15 at 23:36
• Sorry, I don't have time for write up. Please check the github for the most recent commits. – JohnHanks Jan 11 '15 at 23:54