ArtForz
posted here how the timestamp constraints can be gamed to walk backwards the timestamps used in difficulty adjustments.
While a 51% attack is still incredibly difficult, this bug greatly increases the potential damage if there is one.
In bitcoin.pdf, a 51% attack was supposed to be at least somewhat limited:
"Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air... An attacker can only try to change one of his own transactions to take back money he recently spent."
With the time warp bug, a 51% attacker
can create value out of thin air by lowering the difficulty to 1 and generating the remaining 11 million BTC of block rewards for himself. Time warp keeps rewinding time to fit unlimited blocks before the current time. (I think ArtForz actually demonstrated the attack on one of the altcoins)
Since time warp chains are so distinctively different from anything the real network would ever generate, it should be possible to come up with a way to block them without causing compatibility problems.
Rule Idea #2:
Rule: A block is invalid if timestamp is more than 24 hours after GetMedianTimePast()
This limits the divergence between GetMedianTimePast() and single timestamps that the time warp takes advantage of. The time warp depends on making single timestamps far in the future and jumping back to the old time before the median is affected.
It would really only need to apply to the two blocks involved in difficulty adjustment calculations. (only 2 out of 2016 blocks)
It's hard to imagine there ever being a 24 hour gap in practice, but just in case, miners should cap timestamp at GetMedianTimePast() + 24 hours. (this part wouldn't require universal miner support, just enough to push through 2 blocks)