My friend(elbandi) found an anomaly in blockchain. The 576751 went back in time compared to prev block 576750
576750: 1410868131 (2014-09-16 11:48:51)
576751: 1410866296 (2014-09-16 11:18:16)
In the wallet there are a
int64 nActualSpacing = pindexPrev->GetBlockTime() - pindexPrevPrev->GetBlockTime();
In this case nActualSpacing went to negative and pushed bnNew to negative too.
576750: 1410868131 (2014-09-16 11:48:51)
576751: 1410866296 (2014-09-16 11:18:16)
In the wallet there are a
int64 nActualSpacing = pindexPrev->GetBlockTime() - pindexPrevPrev->GetBlockTime();
In this case nActualSpacing went to negative and pushed bnNew to negative too.
We know this.
This is what was not implemented for PoW in Diamond. We implemented it for PoS only. (long story)
Your suggested fix to make bnTarget 'unsigned' will work. We have other options too, such as letting it be < 0 for a while. Then the time pacing code will kick in and it won't become negative again.
Do you have code suggestion to fix the mantissa/characteristic in the block generator?
In GetNextTargetRequired, replace the end with this:
...
CBigNum bnNew;
bnNew.SetCompact(pindexPrev->nBits);
int64 nTargetSpacing = fProofOfStake? nStakeTargetSpacing : min(nTargetSpacingWorkMax, (int64) nWorkTargetSpacing * (1 + pindexLast->nH
eight - pindexPrev->nHeight));
int64 nInterval = nTargetTimespan / nTargetSpacing;
bnNew *= ((nInterval - 1) * nTargetSpacing + nActualSpacing + nActualSpacing);
bnNew /= ((nInterval + 1) * nTargetSpacing);
if (bnNew > bnTargetLimit)
bnNew = bnTargetLimit;
uint32_t newnbits;
newnbits=bnNew.GetCompact();
//compact format: (M=mantissa, K=characteric)
//nbits= 0xKKMMMMMM, bnNew=0xMMMMMM <<(8*0xKK-3)
//0xMMMMMM max allowed value 0x7FFFFF, because of it is signed(OMG).
if ( newnbits & 0x00800000 )
newnbits=( ( newnbits & 0xFF000000 ) + 0x01000000 ) | ( ( newnbits&0x00FFFFFF )>>8 );
return newnbits;
}
But if you don't let bnNew to be negative, then you don't need this fix. It would be better because this fix multiplies the target with -1, therefore it probably produces other bugs which could be exploited by negative times and fuck ups the diff(there are only one pros: the blockchain will not stop under time hopping attack).
I see Bitcoin has now different SetCompact/GetCompact code, but this might far too dangerous to change in haste. The 'always positive' code might be better -- although not sure it is very portable..
