Search content
Sort by
Showing 4 of 4 results by OverQuantum
1) Real time list of blocks, including orphaned ones
I think, this could be also useful also estimating - how blocks to wait for considering transaction fixed in block chain.Ex. if statistics shows, that one block is orphaned with 1% probability, 2 blocks with 0.01%, 3 blocks with 0.0001%, so it does not require to wait 4th block if you are not afraid of <0.0001% probability.
Re: Truncation bug in GetDifficulty() - 157416.4 vs 157426.2
Sent to github
https://github.com/bitcoin/bitcoin/issues/236
https://github.com/bitcoin/bitcoin/issues/236
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;
}
{
// 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...