Blockchain fully synced, but `bitcoin-cli -getinfo` shows `verification progress: 99.9999%`

lasermind commented at 7:58 pm on November 10, 2023: none

Is there an existing issue for this?

I have searched the existing issues

Current behaviour

Although the blockchain is synced, after some minutes, bitcoin-cli -getinfo does not display verification progress: 100.0000% any more, but drops to 99.9999% and even below.

New block arrived: verification-1000000

After two minutes: verification-999999-hl

After some more minutes: verification-999997-hl

Is there a technical reason for such a behaviour? Or is this just probabilistic assumption that maybe a new block could have been mined somewhere, but not delivered to a node yet?

Expected behaviour

When a new block was downloaded (and verified), the verification progress should stay at 100.0000% and not drop with time – at least as long a new header is know to the node.

verification-1000000

Steps to reproduce

Wait for a new block and call bitcoin-cli -getinfo. Should display verification progress: 100.0000%.

Wait some minutes and call bitcoin-cli -getinfo. Will probably display verification progress: 99.999% or below.

Relevant log output

2023-11-10T19:29:22Z UpdateTip: new best=00000000000000000002cb8883317f93a44e213a584a62bf3ccef3274f22353c height=816190 version=0x32cb8000 log2_work=94.530644 tx=917108469 date=‘2023-11-10T19:28:52Z’ progress=1.000000 cache=151.1MiB(1075120txo) 2023-11-10T19:29:20Z [net] Saw new cmpctblock header hash=00000000000000000002cb8883317f93a44e213a584a62bf3ccef3274f22353c peer=5 2023-11-10T19:29:20Z Saw new header hash=00000000000000000002cb8883317f93a44e213a584a62bf3ccef3274f22353c height=816190

How did you obtain Bitcoin Core

Pre-built binaries

What version of Bitcoin Core are you using?

v25.0.0

Operating system and version

Debian 5.1.127 x86_64 (MyNode 0.3.18)

pinheadmz commented at 8:56 pm on November 10, 2023: member

You’ll find this question on stack exchange:

https://bitcoin.stackexchange.com/search?q=Progress

It can happen if the most recent block was mined too long ago. Essentially the node can only estimate how many blocks “should be” in the chain given the time. Your node doesn’t know if there is a longer chain out there than what it already has, and so “progress” is just a guess.

Edit: hm actually the SE questions don’t really cover this. I’ll add it there !

lasermind commented at 9:18 pm on November 10, 2023: none

I’m inclined to agree, that such a “probabilistic decrease” could be done when really the most recent block was mined “too long ago”. But it happens regularly even after two minutes. This can’t be “too long ago” when it is to assume that a new block happens every 10 minutes.

Also note: I’m not talking about the progress from the log file, which seems to sit happily at 1.000000. I’m talking about the verification progress value, output by the command bitcoin-cli -getinfo, which starts to decrease after a few minutes to 99.9999% and below.

sipa commented at 9:21 pm on November 10, 2023: member

@lasermind A node is always synchronizing. It is never “done”, because it cannot know whether a later block was already mined. So the number is just a ratio between the number of blocks it has divided by a guess for how many blocks should exist, on average. Even briefly after a block, it will be less than 100%.

maflcko added the label Questions and Help on Nov 11, 2023

maflcko removed the label Questions and Help on Nov 11, 2023

maflcko added the label RPC/REST/ZMQ on Nov 11, 2023

lasermind commented at 6:08 pm on November 11, 2023: none

Ok, now this is exactly what I’m talking about: on average a new block is mined every 10 minutes. This is the fundamental assumption, isn’t it? So it does not make much sense to arbitrarily decrease this “guessed value” earlier than 10 minutes.

At least for the first 10 minutes, it could stay at 100.0000%.

That’s basically all I’m saying here.

sipa commented at 6:15 pm on November 11, 2023: member

63% of blocks take less than 10 minutes, and the shorter the interval, the more likely it is (39% takes less than 5 minutes, for example, and 9% takes less than 1 minute). There is nothing special about the value 10 minutes except that’s the average internal when averaged over many blocks.

maflcko commented at 12:40 pm on November 12, 2023: member

Maybe it could be split into two fields? One with “header progress”, which is equal to the number returned here (including presumed existing, but unknown headers), and another one “verification progress”, which reflects the blocks fully verified up to all known headers (excluding the presumed existing, but unknown headers)?

CubicEarth commented at 10:49 am on March 12, 2024: none

@sipa - You make a good point. But in terms of the what is reported to the user, the semantics of “verification progress” does not convey any of the nuance you speak of. I agree that something along the lines of what @maflcko is talking about would be more clear. The “verification progress” could be as a function of known headers, and then there could be a field showing elapsed time since the most recent header.

The reality is that a node can be fully synchronized, although its work of constantly searching for new headers and blocks is never-ending. So perhaps it would be technically correct to say both it is fully synchronized (100%), and yet it is still “synchronizing” at the same time. But if the term can have these dual meanings, it can lead to confusion.

Blockchain fully synced, but bitcoin-cli -getinfo shows verification progress: 99.9999% #28847