getblockchaininfo verificationprogress never reaches 1.0 #31127

issue casey openend this issue on October 22, 2024
  1. casey commented at 0:30 am on October 22, 2024: contributor

    In the output of bitcoin-cli getblockchaininfo, verificationprogress sometimes never reaches 1.0, and fluctuates around 0.99999.

    0{
    1  ...
    2  "verificationprogress": 0.9999945316157191,
    3  ...
    4}
    

    This was reported in #26433, and closed because verificationprogress is only an estimate. I would have commented in that issue, but it’s locked. The rationale for closing the issue was because the OP in the issue wanted to use verificationprogress to check if the chain is synced, and the field is only an estimate, and shouldn’t be relied on as exact.

    This makes sense, however, however, I think it still should be fixed so that, at the chain tip, verificationprogress is 1.0, just for UX reasons. Many a time I’ve looked at the output of getblockchaininfo and been confused because it isn’t at 1.0.

  2. jonatack commented at 1:03 am on October 22, 2024: member
    Maybe for UX purposes verificationprogress in RPCs getblockchaininfo and getchainstates (and CLI -getinfo) could return 1 instead of the estimate, when blocks equals headers or validated is true.
  3. sipa commented at 1:11 am on October 22, 2024: member

    The verification progress estimate is computed by first determining an estimate on the total number of transactions to date (based on the current time, and a known growth rate), and then dividing the actual number of transactions in the chain by that.

    If we want something that looks nicer, it’s possible to instead of using the current time, use the timestamp of the best known block header. This will give wildly inaccurate results while headers are still syncing, though.

  4. laanwj added the label RPC/REST/ZMQ on Oct 22, 2024
  5. laanwj commented at 7:25 am on October 22, 2024: member
    Looks like a duplicate of #26433.
  6. jonatack commented at 3:20 pm on October 22, 2024: member

    Maybe for UX purposes verificationprogress in RPCs getblockchaininfo and getchainstates (and CLI -getinfo) could return 1 instead of the estimate, when blocks equals headers or validated is true.

    Proposed in #31135.

  7. pinheadmz commented at 7:17 pm on May 15, 2025: member
    This is a FAQ but is always closed as not planned. In my opinion, progress is only useful the first day you start a node to get some idea how long it’ll take to be useable. I believe lnd returns synced: true whenever the tip timestamp is within two hours of now. I don’t think bitcoind should “round up” the progress to 1 for UX reasons, the user or api consumer should decide on their own how risky their use case is it has been more than 0 seconds since receiving a new block.
  8. jonatack commented at 7:26 pm on May 15, 2025: member

    I think it’s also useful when your node comes back online after a shutdown or an outage (I have -getinfo along with -netinfo running as live watch dashboards, along with the debug log).

    the first day you start a node

    One day to sync 😍 last 3 times I synced a node, it took between 10 days and 5 weeks depending on internet bandwidth + reliability.

  9. pinheadmz marked this as duplicate on May 15, 2025
  10. maflcko commented at 11:34 am on May 16, 2025: member
    See #32528
  11. achow101 closed this on May 27, 2025

  12. pull[bot] referenced this in commit 88b22acc3d on May 27, 2025

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2025-05-30 12:12 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me