Quote from: 24Kilo on September 28, 2014, 11:02:18 PM

I have to run the numbers, but retargeting difficulty with a time component will create vulnerability to a TW(Time Warp) attack. Just doing a quick simulation here tells me that a TW attack would be successful with less than 10% of the total nethash.

I could very easily create a side chain by manipulating timestamps on the blocks to appear to have 150sec block times with minimal hash-rate that could be merged into the main chain at any point even if you implemented a centralised network time server because the blocks are no longer comfirmed by proof of work, but by time stamp.

As I see it, you would need very little nethash for a successful TW attack.

Example:
nTargetSpacing = 2.5 min
minBlockTime = 1 min

A solved block comes in that took less than minBlockTime (using time diff between blocks like it is used for diff recalculation anyway).
Block gets rejected, diff recalculates to i.e. 1.5 times what it was before (so that the expected time for this block gets above the minBlockTime) and the network notified about the new diff.
This catch would only kick in if the times to solve a block are getting below the set minimum.
If the times are in the allowed range, the normal diff adjusting will do its work and level it out again.

How would a time warp attack work here? What am I missing?
Wouldn't the normal diff calculation (DGW3 here) be vulnerable to it too if you can use the number of blocks of an interval in a row for it?
Coins like UTIL or SLG are using an algo with far less blocks per interval and giving the actual block time double weight to calculate the diff modification factor. Wouldn't they be vulnerable even more?