Quote from: subSTRATA on August 02, 2014, 06:19:06 PM

Quote from: Mike270 on August 02, 2014, 04:50:49 AM

Just my 10 cent:
As far as I can tell, the last two proof-of-stake blocks were 467226 and 467227.
Block 467226 was set two hours into the future, i.e.
467225 blocktime 07/30/14 07:47:33 (PoW)
467226 blocktime 07/30/14 09:47:05 (PoS)
467227 blocktime 07/30/14 07:47:32 (PoS)

Presumably whoever mined that block had a system clock that was way off...

in main.cpp, nActualSpacing is calculated as the time that passed between the last two PoS blocks (which in this case would be negative!)
This value is then used for calculating block difficulty bnNew.
I'm not that much into the mechaincs of block difficulty, but I could imagine that this leads to an insanely high block difficulty for PoS minting (bnTargetLimit?)
Perhaps we need a failsafe for negative time between last two PoS blocks?

It can not be difficulty is calculated based on just 2 last blocks, that would be foolish. All cryptocoins use at least few hundred blocks for PoW and PoS difficulty retargeting.
And I totally doubt it took 467226 blocks for the first ever occurence of PoS block with timestamp in future.

Look at GetNextTargetRequired() closer. Do the math, the tipping point isn't at nactualspacing=0. Although setting nactualspacing to bottom out at 0 does solve the problem.