Sent to github
https://github.com/bitcoin/bitcoin/issues/236
Topic: Truncation bug in GetDifficulty() - 157416.4 vs 157426.2 (Read 1157 times)
I've also heard reports that the latest version gives slightly different difficulty numbers than old versions. It's pretty much impossible to calculate the "official" difficulty. I would prefer division of long numbers.
It seems to me, that GetDifficulty() function in rpc.cpp have truncation problem which is already observer now and could lead to further problems, up to division by zero.
1) http://blockexplorer.com/b/124677 -> Difficulty?: 157 416.401843 ("Bits"?: 1a6a93b3)
2) http://blockexplorer.com/q/getdifficulty -> 157426.20628986
Why so?
hextarget = 0000 0000 0000 6A93 B300 00000000000000000000000000000000000000000000
maxtarget = 0000 0000 FFFF 0000 0000 00000000000000000000000000000000000000000000
If we divide them, result will be 157416.4018436490, value in block's info.
Problem is in getdifficulty function:
So, bnProofOfWorkLimit >> nShift = 0x7FFF8000
while nBits >> nShift = 0x3549
return will be 157426.20628986100 that we observe on blockexplorer's getdifficulty and in bitcoin client.
From 24 "mantissa" bits of hextarget only 15 are used, and problem will increase with difficulty. At 2 billions will will get divison by zero.
Sorry, if it was disscussed, I have not found any mentions...
1) http://blockexplorer.com/b/124677 -> Difficulty?: 157 416.401843 ("Bits"?: 1a6a93b3)
2) http://blockexplorer.com/q/getdifficulty -> 157426.20628986
Why so?
hextarget = 0000 0000 0000 6A93 B300 00000000000000000000000000000000000000000000
maxtarget = 0000 0000 FFFF 0000 0000 00000000000000000000000000000000000000000000
If we divide them, result will be 157416.4018436490, value in block's info.
Problem is in getdifficulty function:
Code:
double GetDifficulty()
{
// Floating point number that is a multiple of the minimum difficulty,
// minimum difficulty = 1.0.
if (pindexBest == NULL)
return 1.0;
int nShift = 256 - 32 - 31; // to fit in a uint
double dMinimum = (CBigNum().SetCompact(bnProofOfWorkLimit.GetCompact()) >> nShift).getuint();
double dCurrently = (CBigNum().SetCompact(pindexBest->nBits) >> nShift).getuint();
return dMinimum / dCurrently;
}
So, bnProofOfWorkLimit >> nShift = 0x7FFF8000
while nBits >> nShift = 0x3549
return will be 157426.20628986100 that we observe on blockexplorer's getdifficulty and in bitcoin client.
From 24 "mantissa" bits of hextarget only 15 are used, and problem will increase with difficulty. At 2 billions will will get divison by zero.
Sorry, if it was disscussed, I have not found any mentions...
Jump to: