blocks are staking too slowly

[dooglus]

The target time per block is 1 minute, but we're seeing around half that rate. The last two days we've seen around 700 blocks per day.

I looked to see why that is, and found:

1. we are often at the minimum difficulty

CBigNum bnProofOfStakeLimit(~uint256(0) >> 20);

changing the 20 to 18 or something would probably fix the problem by increasing the max target / decreasing the min difficulty.

2. GetNextTargetRequiredV2() in main.cpp effectively does this for each block to get 'new' difficulty from 'old':

new = old * (15 * currentTargetSpacing + nActualSpacing + nActualSpacing) / (17 * currentTargetSpacing)

Issue #4 means that it's not unusual for two blocks to have the same timestamp, causing nActualSpacing to be 0, and causing a 2/15 = 13.3% leap in difficulty which then takes a while to recover from.

Changing bnProofOfStakeLimit would cause a hard fork.

[dooglus]

The situation seems to be getting worse:

block          timestamp
-----  -----------------
36182  14-07-16 12:01:36
36495  14-07-17 00:01:54 average 138 seconds per block
36808  14-07-17 12:02:29 average 138 seconds per block
37128  14-07-18 00:01:39 average 135 seconds per block
37499  14-07-18 12:00:12 average 116 seconds per block
37820  14-07-19 00:19:25 average 134 seconds per block
38197  14-07-19 12:02:45 average 114 seconds per block
38558  14-07-20 00:04:27 average 119 seconds per block
38793  14-07-20 12:04:47 average 183 seconds per block
38887  14-07-20 18:05:35 average 229 seconds per block

1. At minimum difficulty, we need a network stake weight of around 17000 clam days to get 1 minute blocks:

>>> 2**20 / 60
17476

My client currently tells me the network weight is 4769. That's about 3.5 times less than 17476, which explains why we're getting 3.5 minute blocks, not 1 minute blocks.

Making the minimum difficulty lower would allow us to go back to 1 minute blocks:

>>> 2**18 / 60
4369

>>> 2**16 / 60
1092

2. The retarget code really needs to look at the time taken for the last 16 blocks not just the last 2. It currently puts too much importance on the time between a single pair of blocks.

If there's any interest in fixing these two issues, I'll write code to fix them both.

Do we have other hard-fork changes planned that these can get bundled in with?

[dooglus]

#25 fixes this.