Truncation bug in GetDifficulty, rpc.cpp #236

It seems to me, that GetDifficulty() function 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. bitcoin.exe getdifficulty -> 157426.20628986 (at the moment) 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: 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 in bitcoin client, on blockexplorer's getdifficulty and so on.

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.

Seems like a nice, well-defined problem for somebody new to tackle. Conversion of difficulty to floating point isn't a critical function (internally it is all uint256's), and we're not going to get to 2 billion difficulty soon, so not high priority.