The progress on log sometimes shows like 0.999971, 1.000001 or 1.000009 what is impossible, and should be 1.000000. This must be a precision error.
I imagine this little bug does not affect the Bitcoin UI, only the log files.
Where to modify:
src/main.cpp - Line 1907 at 2b45345aaca9d0091972f983ac6e5c0b09d14777 LogPrintf("UpdateTip: ...");
Related commit: 9f2467ad6241ce6cf0897ed30c676598d59441a7
NOTE: This is a just slight improvement and very low priority.
I imagine that this is not a precision error, but simply an inability to know it for sure.
The function is called GuessVerificationProgress which has 'Guess' in the name. It is never used for critical tasks, just for coarsely reporting progress.
Sure. But even guessing it is possible to know the number can't be bigger than 1.0, at least. But if it is only for the log and does not affect anything more, I guess this bug should not be fixed.
The method GuessVerificationProgress returns number bigger than 1 if the last known block's time is in the future compared to our system time (from time(NULL) - compare https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp#L64). This can happen if our time is bad or if the received block comes with future time (which is perfectly valid as we accept blocks that can be 2 hours in the future based on the adjusted time - see https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2366). In such cases, we are really "in the future"/ahead compared to our expectations. So number bigger than one is perfectly OK here. This issue can be closed.
We could 'fix' it by subtracting 2 hours from the clock first, but that would on average result in getting less close to 1.0.
Can we return 1.0 if the last block is in the future?
I kind of like the 1.XXX, it counters the perception that 0.9999XX implies you aren't caught up, even though you are.
I do not think we have to fix the code - good explanation is enough IMO.
Agreed. I don't think this needs to be fixed either. Closing.