Bitcoin-Qt: never display own block count > estimated block count #2148

Diapolo commented at 9:22 PM on January 3, 2013: none

some users reported it as weird, that the estimated block count could be lower than our own nodes block number (which is indeed bad)
this pull adds a new default behaviour, which displays our own block number as estimated block number, if own >= est. block count
the pull raises space for nodes block counts in cPeerBlockCounts to 8 to be more accurate
also removes a reduntant setNumBlocks() call in RPCConsole and moves initialisation of numBlocksAtStartup in ClientModel, where it belongs

BitcoinPullTester commented at 9:37 PM on January 3, 2013: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/a79bb07800bbc8c72cf97cf8b34e9137ea84b03a for binaries and test log.

Bitcoin-Qt: never display own block count > estimated block count

- some users reported it as weird, that the estimated block count could be
  lower than our own nodes block number (which is indeed true and not good)
- this pull adds a new default behaviour, which displays our own block
  number as estimated block number, if own >= est. block count
- the pull raises space for nodes block counts in cPeerBlockCounts to 8 to
  be more accurate
- also removes a reduntant setNumBlocks() call in RPCConsole and moves
  initialisation of numBlocksAtStartup in ClientModel, where it belongs

54413aab13

in src/qt/clientmodel.cpp:None in a79bb07800 outdated

  62 | @@ -65,7 +63,11 @@ void ClientModel::updateTimer()
  63 |          cachedNumBlocks = newNumBlocks;
  64 |          cachedNumBlocksOfPeers = newNumBlocksOfPeers;
  65 |  
  66 | -        emit numBlocksChanged(newNumBlocks, newNumBlocksOfPeers);
  67 | +        // ensure we return newNumBlocks as "num blocks of peers", when newNumBlocks >= newNumBlocksOfPeers
  68 | +        if (newNumBlocks < newNumBlocksOfPeers)
  69 | +            emit numBlocksChanged(newNumBlocks, newNumBlocksOfPeers);
  70 | +        else
  71 | +            emit numBlocksChanged(newNumBlocks, newNumBlocks);

sipa commented at 2:55 AM on January 4, 2013:

wouldn't "emit numBlocksChanges(newNumBlocks, std::max(newNumBlocksOfPeers, newNumBlocks))" be the same?

Diapolo commented at 4:16 PM on January 4, 2013:

Yeah, that's better, thanks for mentioning :).

BitcoinPullTester commented at 4:43 PM on January 4, 2013: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/54413aab135aa84f60bfcb477a4d2ecfb72edbac for binaries and test log.

laanwj commented at 3:44 PM on January 5, 2013: member

ACK

laanwj referenced this in commit eb5c24c464 on Jan 5, 2013

laanwj merged this on Jan 5, 2013

laanwj closed this on Jan 5, 2013

luke-jr commented at 4:43 AM on January 16, 2013: member

Is there some background to this? I don't understand why...

robbak commented at 5:51 AM on January 16, 2013: contributor

The client estimates the current block count by averaging the block counts of connected clients. When you have just received the latest one, then your block count can be above the average.

Nothing to see here, move along.

On 16 January 2013 14:43, Luke-Jr notifications@github.com wrote:

Is there some background to this? I don't understand why...

— Reply to this email directly or view it on GitHubhttps://github.com/bitcoin/bitcoin/pull/2148#issuecomment-12304731.

laudney referenced this in commit 528145080a on Mar 19, 2014

HashUnlimited referenced this in commit f577dc80f0 on Jul 2, 2018

HashUnlimited referenced this in commit 1f0f6d7b5d on Jul 2, 2018

HashUnlimited referenced this in commit 7d8e94bcb1 on Jul 2, 2018

HashUnlimited referenced this in commit c80fe9a263 on Jul 3, 2018

sidhujag referenced this in commit 1883927618 on Jul 13, 2018

owlhooter referenced this in commit 26c891f67f on Oct 11, 2018

guruvan referenced this in commit 2ccfffc87d on Nov 8, 2018

DrahtBot locked this on Sep 8, 2021