Usually while syncing, I see an orange circular icon in the bottom right corner of the GUI:
http://i41.tinypic.com/n1uy2w.png
But today, after updating from git and rebuilding, I saw a green checkmark there, which usually indicates that the local copy of the blockchain is up-to-date. However, the status bar said it was syncing, and only 99% done:
Are you running 0.6 release candidate 1?
If you are, please upgrade to release candidate 2. If you can't upgrade for some reason, you need to run with the -paytoscripthashtime=1333238400 flag to get onto the right blockchain.
I was running the latest git HEAD. It's newer than rc2, and I was also using the ...hashtime flag, having been affected by the blockchain fork earlier in the day.
The issue I'm reporting is that the checkmark appears some time before the 99% progress bar disappears, giving conflicting information. I don't know what is happening in the time between the orange circle changing to a green checkmark and the progress bar disappearing, but it can take several seconds to happen.
It's still happening in git HEAD and official v0.6.0 release.
Screenshot:
And:
Perhaps this can be fixed by a small edit in bitcoingui.cpp.
Change line ~555 from: "if(secs < 90_60)" to "if(secs < 90_60 && count == nTotalBlocks)"
Could you try it?
I'll try it. I need to let the blockchain advance with bitcoin-qt shut down so there's something to catch up, so it will take a while.
Your change looks right though. The code was previously saying "if we have a block that's less than 90 minutes old then were up to date".
I often see the client gets stuck with 1 or 2 blocks to download; probably due to the mini blockchain forks which keep happening when non BIP-16 clients generate a block that BIP-16 clients won't accept.
If you say my change works I'll create a small pull-request asap :).
I tried it. It works sometimes, but mostly it just leaves the spinning orange circle icon showing.
It turns out that typically, count is 175517 and nTotalBlocks is 168000.
nTotalBlocks is from GetNumBlocksOfPeers() in main.cpp: return std::max(cPeerBlockCounts.median(), Checkpoints::GetTotalBlocksEstimate());
and cPeerBlockCounts has 2 values in it when we check, the initial 0 and 175517 from the first peer we connected to. The median of these two is 87758 and so max() returns the highest checkpoint: 168000
I can modify the code to ignore the initial 0 in the vector, but that doesn't help with the other problems:
Even as new connections come in and fill the (5 slot) cPeerBlockCounts vector, the spinner icon keeps spinning. It will only be changed when setNumBlocks() is run again, which is only triggered by a numBlocksChanged signal. This also causes the tooltip on the checkmark to say things like "last received block was generated 3 minutes ago" for 10 minutes at a time. The "3 minutes ago" is generated once, and not updated as the newest block ages.
Sometimes when I run bitcoin-qt we have 2 connections before the median is checked, and in that case the green check mark appears correctly because the median of [0, correct, correct] is correct.
When a new block is generated my client gets it pretty quickly, but the vector used to calculate nTotalBlocks is only updated when we first connect to each peer, and so doesn't reflect the new blockchain length:
SetBestChain: new best=0000000000000226709b height=175523 work=292688024487397697436
block counts: [ 140700 175522 175522 175522 175522 ] median 175522, max 175522
and so the icon goes back to the orange spinner.
It should be count >= nTotalBlocks. After the initial block chain download, count will exceed nTotalBlocks.
@laanwj The problem with that is that I often see nTotalBlocks = 168000 (the most recent checkpoint), so your proposed condition is true, and the green check mark is shown incorrectly. See my comment 2 up from this one for details of why that happens.
Even if we fix the median code to ignore the 0 value, there's still a problem if the first peer we connect to is still downloading the blockchain. We'll set nTotalBlocks to the number of blocks that peer has, see that we have more, and so show the green checkmark.
If that's the solution, you can open the pull-request :). I'm off now, cya!
@dooglus that's why we should check both secs < 90*60 and count >= nTotalBlocks.
You complaint was that the progress bar is shown with the green checkmark. The progress bar is only shown when count < nTotalBlocks.
So the proposed change will mean they are never shown at the same time.
We use the last checkpoint as initial estimation of the total number of blocks, but this will quickly change as soon as some connections are made. That's on purpose, nTotalBlocks is always going to be lagging with the current protocol.