<p>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 <a href="https://github.com/myriadcoin/myriadcoin" rel="nofollow">https://github.com/myriadcoin/myriadcoin</a> would be a good idea for anyone interested in solving timewarp issues.</p>

CC BY-SA 3.0
2015-01-11T23:36:38.307Z
So, what was their solution?
Nick ODell
CC BY-SA 3.0
2015-01-11T23:54:25.877Z
Sorry, I don't have time for write up.  Please check the github for the most recent commits.
JohnHanks
CC BY-SA 3.0
2015-01-11T23:34:24.707Z
2015-01-11T23:34:24.707Z
JohnHanks
<p>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.</p>

<p>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.</p>

<p>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 <a href="https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki" rel="nofollow">BIP34</a>, the supermajority of hash rate would be upgraded before the new rule was applied, minimizing disruption.</p>

CC BY-SA 3.0
2015-01-15T06:14:50.457Z
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
CC BY-SA 3.0
2015-01-15T13:30:42.657Z
@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
CC BY-SA 3.0
2015-01-15T13:42:31.820Z
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
CC BY-SA 3.0
2015-01-11T20:21:46.777Z
2015-01-15T13:43:59.260Z
2015-01-15T13:43:59.260Z
David A. Harding
<p><a href="https://bitcoin.stackexchange.com/a/1058">jarpian explains what a time warp attack (AKA zeitgeist attack) is:</a></p>

<blockquote>
  <p>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 <a href="https://bitcoin.stackexchange.com/questions/915/why-dont-the-timestamps-in-the-block-chain-always-increase">timestamps are not required to be in increasing order</a>. ArtForz explains the attack in detail <a href="https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772" rel="nofollow noreferrer"><strong>here</strong></a>.</p>
  
  <p>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.</p>
</blockquote>

<p>Obviously, performing this attack would be horrendously expensive. (Coinometrics places the cost at about <a href="http://www.coinometrics.com/bitcoin/brix" rel="nofollow noreferrer">$463 million</a> at time of writing.)</p>

<p>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. </p>

<p>The obvious way of fixing this - changing the block retarget period from (2016*n, 2016*n + 2015) to (2016*n, 2016*n + <strong>2016</strong>) is problematic. Blocks produced by the new implementation would be invalid in the old implementation, and vice-versa. <a href="https://github.com/bitcoin/bitcoin/blob/729ba317498bf644c62975dbde07da5ab9ef0043/src/main.cpp#L2565" rel="nofollow noreferrer">(Source)</a></p>

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

CC BY-SA 3.0
2015-01-07T15:35:05.643Z
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
<security><timestamp><time-warp-attack>
How could a time warp attack be prevented?
Nick ODell
# How could a time warp attack be prevented?

(Asked by: username_0 on 2015-01-07)

[jarpian explains what a time warp attack (AKA zeitgeist attack) is:](https://bitcoin.stackexchange.com/a/1058)

> 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](https://bitcoin.stackexchange.com/questions/915/why-dont-the-timestamps-in-the-block-chain-always-increase). ArtForz explains the attack in detail [**here**](https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772).
>
> 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](http://www.coinometrics.com/bitcoin/brix) 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)](https://github.com/bitcoin/bitcoin/blob/729ba317498bf644c62975dbde07da5ab9ef0043/src/main.cpp#L2565)

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

**Tags:** security, timestamp, time-warp-attack

> **Comments:**
> **username_1**: 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.  

---

## 2 answers

### Answer by username_3 on 2015-01-11. Score: 5 | Accepted answer

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](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki), the supermajority of hash rate would be upgraded before the new rule was applied, minimizing disruption.

> **Comments:**
> **username_0**: 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.  
> **username_3**: @username_0 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.  
> **username_3**: 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.  

---

### Answer by username_2 on 2015-01-11. Score: -4

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.

> **Comments:**
> **username_0**: So, what was their solution?  
> **username_2**: Sorry, I don't have time for write up.  Please check the github for the most recent commits.  

---

