difficulty code is vulnerable about clams HOT 8 CLOSED

This attack may be currently underway, which is what made me think of it:

SetBestChain: height=46089  trust=60699904650  target=205  date=07/31/14 05:53:20
SetBestChain: height=46090  trust=60720850521  target=205  date=07/31/14 05:52:54 <-- older than previous
SetBestChain: height=46091  trust=60743873085  target=186  date=07/31/14 05:53:29
SetBestChain: height=46092  trust=60768082870  target=177  date=07/31/14 05:53:10 <-- older than previous
SetBestChain: height=46093  trust=60792292655  target=177  date=07/31/14 05:54:08
SetBestChain: height=46094  trust=60816598237  target=176  date=07/31/14 05:53:58 <-- older than previous

We've seen 709 blocks in the last 9 hours - an average of 79 blocks per hour.

from clams.

Troubling.... this would require a hard-fork.
Might be wise to set some type of limit to how 'negative' nActualSpacing is allowed to go...?

from clams.

I already committed a change which averages the time-per-block over more than just 2 blocks, which fixes this problem. If we're going to reduce the minimum difficulty then that's a hard-fork anyway, and this can be changed at the same time.

from clams.

#25 is the fix for this - it has been merged in 'develope', but maybe not to master?

from clams.

In reply to a PM from CC:

Am I to assume this fix (which should have been included in the recent hard-fork) sumarizes the problem, and we are in the middle of a time-warp-esque attack?

#51

At that time we were seeing 3-minute blocks, due to not enough people (or coins) staking, so my pull request reduces the minimum difficulty as well as averaging the time-per-block over the last N blocks rather than just the last one.

The problem we're seeing at the moment is that if the timestamp goes back 5 minutes, difficulty stays the same, but if it then goes forward 5 minutes, it looks like the last block took 5 minutes to find, and so the difficulty drops. This happens over and over again, and so the difficulty stays artificially high.

Averaging over the last 10 (say) blocks rather than just the last block will solve this.

I'll make a new pull request that does just that.

from clams.

Am I correct in assuming this has been solved and can be closed?

from clams.

Indeed. I'll close it now.

For the record, after the recent hardfork, difficulty reached its new equilibrium at around block 204200 (timestamp 1415714752) and we recently staked block 210200 (timestamp 1416077040).

The average time per block for those 6000 blocks:

>>> (1416077040 - 1415714752) / (210200 - 204200)
60.3813 seconds

For comparison, the average time per block for 6000 blocks shortly before the fork:

>>> (1415673111 - 1415446137) / (203000 - 197000)
37.829 seconds

And because I can't stop gathering data to plot:

from clams.

Amazing :)
An error rate of 0.3 seconds per block over 6,000 blocks.
Not bad, considering the timestamp granularity is still off :)

from clams.