GUI misses some header updates when in IBD #65

fanquake commented at 4:39 AM on August 15, 2020: member

Moved from https://github.com/bitcoin/bitcoin/issues/9464. Low prio, could probably just be closed as wont-fix.

OSX 10.12.2, Qt 5.7.1, master at 2a524b8e8fe69ef487fd8ea1b4f7a03f473ed201.

Running with bitcoin-qt -reindex-chainstate, "Number of blocks left" in the modal overlay never updates, and remains as "Unknown. Syncing Headers (446424)...". Even though we've synced > 200'000 blocks. modal

fanquake added the label Bug on Aug 15, 2020

maflcko commented at 5:56 AM on August 15, 2020: contributor

This is only a temporary glitch. Copy of my previous comment:

Confirmed that the issue is still present in current master (5180a86c96) and "fixes itself"/ is worked around when the next header is sent to you. C.f. my comment https://github.com/bitcoin/bitcoin/issues/9464#issuecomment-270362394

arejula27 commented at 3:43 PM on March 27, 2026: none

<img width="1189" height="351" alt="Image" src="https://github.com/user-attachments/assets/e6c33a80-52ac-41df-837a-c24aa5a25855" /> I was syncing my node for first time on an SSD and face this issue. Is it a wontfix or just non prio, do you think i should try to fix it? Ps: there was a diff ~300 blocks since when i took the screenshot the last minned block was 942480

arejula27 commented at 4:18 PM on March 27, 2026: none

During my first full sync I was able to dig a little deeper into what might be causing this.

How to reproduce

I was running my first IBD from an external SSD. At some point the core crasshed cuz a malformed hash due to a disk issue, so I remounted the SSD with sync option.

2026-03-27T11:35:06Z LevelDB read failure: Corruption: block checksum mismatch: /home/arejula27/.bitcoin/chaindata/chainstate/009670.ldb
2026-03-27T11:35:06Z Fatal LevelDB error: Corruption: block checksum mismatch: /home/arejula27/.bitcoin/chaindata/chainstate/009670.ldb
2026-03-27T11:35:06Z You can use -debug=leveldb to get more complete diagnostic messages
2026-03-27T11:35:06Z [error] Error reading from database, shutting down.
2026-03-27T11:35:06Z [error] Error reading from database: Fatal LevelDB error: Corruption: block checksum mismatch: /home/arejula27/.bitcoin/chaindata/chainstate/009670.ldb

When I restarted Bitcoin Core, the chainstate had only persisted up to block ~534k, even though the block files on disk already blocks up to ~634k and the block index had ~942k headers from the previous session. On startup, ActivateBestChain() had to reconnect the ~100k blocks from 534k to 634k to rebuild the chainstate, which took around 57 minutes.



2026-03-27T14:16:25Z block tree size = 942189
2026-03-27T14:16:25Z nBestHeight = 534981
2026-03-27T14:16:25Z initload thread start
2026-03-27T14:16:25Z init message: Starting network threads…
2026-03-27T14:16:29Z UpdateTip: new best=... height=534982  ← initload reconnecting blocks
...

2026-03-27T15:13:39Z initload thread exit          ← 57 minutes later
2026-03-27T15:13:39Z New outbound-full-relay v2 peer connected: version: 70016, blocks=77225, peer=97
2026-03-27T15:13:39Z New block-relay-only v2 peer connected: version: 70016, blocks=942482, peer=99
2026-03-27T15:13:39Z Synchronizing blockheaders, height: 942482 (~100.00%)
2026-03-27T15:13:40Z New block-relay-only v2 peer connected: version: 70016, blocks=941347, peer=100
2026-03-27T15:13:41Z UpdateTip: new best=00000000000000000001c368b208bb4614a3359cd44a0d47e5574e7c8d0be923 height=634604 version=0x20000000 log2_work=92.029697 tx=538756745 date='2020-06-13T21:19:45Z' progress=0.404176 cache=205.0MiB(1488013txo)

During that entire reconnection period, the node considers itself to still be "loading blocks", which means it ignores incoming headers from peers. Meanwhile, the GUI already had 942k headers loaded from the block index on disk, but bestHeaderDate, the timestamp used to estimate sync progress, was hours out of date, since no new headers had been received. This caused the progress overlay to display "Unknown" for both blocks remaining and estimated time. Once the reconnection finished, the node accepted a new peer connection, fetched the latest headers, and the GUI immediately started showing correct progress information.

Possible cause

During the UTXO rebuild phase (e.g. after a chainstate corruption), LoadingBlocks() returns true, which causes the node to reject incoming headers from peers. This means bestHeaderDate, the timestamp of the last known header, doesn't get refreshed

As time passes, bestHeaderDate becomes stale. After ~4 hours (HEADER_HEIGHT_DELTA_SYNC * nPowTargetSpacing), estimateNumHeadersLeft exceeds the threshold of 24 and the GUI falls into the else branch, displaying "Unknown" for blocks remaining. Meanwhile, UpdateHeaderSyncLabel() computes a percentage that rounds to 100.0% because the few estimated missing headers are negligible relative to the total (~942k). This creates a contradictory display: "Unknown. Syncing Headers (942188, 100.0%)".

Proposal

The "Unknown" + "100.0%" contradiction happens because the percentage rounds up even when there are still headers left. Truncating instead of rounding would make it consistent, 100.0% would only show when headers are actually up to date. I have write the code, i will do a PR in the next days :D