Name is not important, just lfm if you insist. Main point is to fix it. Interesting changes for "coding standards". I am not real good at following other people's styles that way.
Topic: difficulty loss of significance error (Read 1365 times)
See https://github.com/sipa/bitcoin/commit/5e1e458ecb0f5d8e42e1a7fc3b8f9e1d37f52e46
I changed it a bit to match the coding standards, and removed the if test before the while loops.
Which name do you want on it?
I changed it a bit to match the coding standards, and removed the if test before the while loops.
Which name do you want on it?
Attached file is a diff -c patch for the loss of accuracy in the difficulty calculation. For instance any nBits compressed value from 0x1a44b800 thru 0x1a44b9ff will show as difficulty 244139.4816. This patch will more accurately convert the nBits compressed values to the double difficulty.
This will display any of the recent difficulty levels slightly differently though. Early difficulties and testnet difficulties are not large enough to trigger this bug.
None of the actual targets or compressed targets are changed, only the conversion to the floating point difficulty is changed and afaik it is only ever displayed, never converted back so the patch does not effect the target calculations, binary files, databases nor the binary protocol. only programs which use the floating point displayed value of the difficulty might be effected. (pools? I don't think so, but they may need a heads up about the change)
This will display any of the recent difficulty levels slightly differently though. Early difficulties and testnet difficulties are not large enough to trigger this bug.
None of the actual targets or compressed targets are changed, only the conversion to the floating point difficulty is changed and afaik it is only ever displayed, never converted back so the patch does not effect the target calculations, binary files, databases nor the binary protocol. only programs which use the floating point displayed value of the difficulty might be effected. (pools? I don't think so, but they may need a heads up about the change)
Code:
*** bitcoin-0.3.21/src/rpc.cpp 2011-04-20 16:08:01.000000000 -0600
--- bitcoin-0.3.21-test/src/rpc.cpp 2011-05-25 18:20:48.000000000 -0600
***************
*** 199,208 ****
// 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;
}
Value getdifficulty(const Array& params, bool fHelp)
--- 199,220 ----
// minimum difficulty = 1.0.
if (pindexBest == NULL)
return 1.0;
! int shift = (pindexBest->nBits >> 24) & 0xff;
! double diff =
! (double)0x0000ffff / (double)(pindexBest->nBits & 0x00ffffff);
!
! if (shift < 29)
! while (shift < 29) {
! diff *= 256.0;
! shift++;
! }
! else
! while (shift > 29) {
! diff /= 256.0;
! shift--;
! }
!
! return diff;
}
Value getdifficulty(const Array& params, bool fHelp)
--- bitcoin-0.3.21-test/src/rpc.cpp 2011-05-25 18:20:48.000000000 -0600
***************
*** 199,208 ****
// 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;
}
Value getdifficulty(const Array& params, bool fHelp)
--- 199,220 ----
// minimum difficulty = 1.0.
if (pindexBest == NULL)
return 1.0;
! int shift = (pindexBest->nBits >> 24) & 0xff;
! double diff =
! (double)0x0000ffff / (double)(pindexBest->nBits & 0x00ffffff);
!
! if (shift < 29)
! while (shift < 29) {
! diff *= 256.0;
! shift++;
! }
! else
! while (shift > 29) {
! diff /= 256.0;
! shift--;
! }
!
! return diff;
}
Value getdifficulty(const Array& params, bool fHelp)
Jump to: