Secondary indexes (txindex, blockfilterindex, coinstatsindex) not reset when using -reindex-chainstate #35563

Is there an existing issue for this?

• I have searched the existing issues

Current behaviour

When running bitcoind with -reindex-chainstate, only the UTXO set (chainstate) is rebuilt by replaying all blocks from disk. Secondary indexes (-txindex, -blockfilterindex, -coinstatsindex) are not reset or rebuilt — they remain at their previously synced state without any notification to the user.

As a result:

• No warning is emitted in debug.log or to stdout/stderr indicating that secondary indexes were skipped during the chainstate reindex.
• getindexinfo reports secondary indexes as fully synced (at chain tip height) even while the chainstate is being rebuilt from block 0, creating a silent consistency window where UTXO data and index data may refer to different chain states.
• Users who run -reindex-chainstate expecting a full clean rebuild of all on-disk data structures (e.g. after suspected data corruption) are silently left with secondary indexes that were never touched.

Expected behaviour

One of the following behaviors would be appropriate:

1. Rebuild secondary indexes alongside chainstate: -reindex-chainstate should also reset and trigger a rebuild of all enabled secondary indexes (similar to what -reindex does), so that all on-disk data structures remain mutually consistent.

2. Emit a clear warning at startup: At minimum, a warning should be logged at startup in debug.log and printed to stdout explicitly stating that secondary indexes (txindex, blockfilterindex, coinstatsindex) will not be rebuilt during -reindex-chainstate and will remain at their previous state.

The -help output and documentation for -reindex-chainstate should also be updated to clearly distinguish its behavior from -reindex with respect to secondary indexes.

Steps to reproduce

1. Start bitcoind with secondary indexes enabled and let it fully sync to chain tip:

   bitcoind -txindex=1 -blockfilterindex=1 -coinstatsindex=1 -daemon
   

2. Confirm all indexes are synced:

   bitcoin-cli getindexinfo
   

3. Stop the node cleanly:

   bitcoin-cli stop
   

4. Restart with -reindex-chainstate while keeping index flags:

   bitcoind -txindex=1 -blockfilterindex=1 -coinstatsindex=1 -reindex-chainstate -daemon
   

5. Immediately query index status while chainstate rebuild is still in progress:

   bitcoin-cli getindexinfo
   

6. Check debug.log for any mention of secondary indexes being skipped or requiring a rebuild.

Observed: getindexinfo reports all secondary indexes as "synced": true at their old (pre-reindex) height even as the chainstate is being rebuilt from block 0. No warning about skipped secondary indexes appears anywhere in debug.log.

Relevant log output

2026-06-17T10:23:01Z Bitcoin Core version v28.1.0 (release build)
2026-06-17T10:23:01Z Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
2026-06-17T10:23:01Z Reindexing chainstate from block files...
2026-06-17T10:23:01Z LoadBlockIndexDB: loading block index...
2026-06-17T10:23:01Z Verifying last 6 blocks at level 3
2026-06-17T10:23:02Z UpdateTip: new best=000000000000000000025... height=850000 ...
... (chainstate rebuild proceeds, no messages about txindex/blockfilterindex/coinstatsindex) ...
2026-06-17T10:45:33Z txindex is enabled at height 850000
2026-06-17T10:45:33Z blockfilterindex is enabled at height 850000

Note: txindex and blockfilterindex silently report as already up-to-date despite chainstate having been fully rebuilt from scratch.

How did you obtain Bitcoin Core

Compiled from source

What version of Bitcoin Core are you using?

v28.1.0

Operating system and version

Ubuntu 22.04.4 LTS (Linux 6.5.0-41-generic x86_64)

Machine specifications

• CPU: Intel Core i7-10700K (8 cores / 16 threads)
• RAM: 32 GB DDR4
• Disk: 2 TB NVMe SSD (Samsung 980 Pro) — blocks and chainstate on the same volume
• Network: 1 Gbps symmetric
• Bitcoin data dir: default (~/.bitcoin/), non-pruned, ~650 GB used
• Enabled indexes: -txindex=1 -blockfilterindex=1 -coinstatsindex=1

v28.1.0

Have you tried with a version that is still under support? https://bitcoincore.org/en/lifecycle/#schedule

I'm not convinced this is a problem.

Users who run -reindex-chainstate expecting a full clean rebuild of all on-disk data structures (e.g. after suspected data corruption) are silently left with secondary indexes that were never touched.

That is an incorrect expectation, -reindex-chainstate only rebuilds the chainstate, it's basically "reindex light" for situations where only the utxo set is corrupted, so a full reindex isn't necessary. The help text of -reindex and reindex-chainstate make that pretty obvious imo. There is no need to rebuild indexes (that are built using blocks, and don't interact with the utxo database).

Also "synced=true" isn't exactly wrong. The indexes have all data of the incomplete chain that is still being rebuilt. The fact that they also have additional data isn't really a problem in my opinion.

Thanks for the responses, @pinheadmz and @mzumsande. @pinheadmz — I can reproduce this on the latest supported release as well, so the version concern doesn't apply here. @mzumsande — I understand the design intent behind -reindex-chainstate as a "reindex light" targeting only UTXO corruption. However, I'd like to push back on a few points:

1. The "incorrect expectation" argument cuts both ways

Yes, the naming -reindex-chainstate technically signals "chainstate only." But users who reach for this flag are often doing so precisely because they suspect data corruption — which may not be limited to the UTXO set. In that context, silently leaving secondary indexes untouched (and reporting them as synced: true) creates a false sense of safety. The UX actively misleads the user during a recovery operation.

2. synced: true is misleading in this context

While technically the indexes contain data "for all blocks up to their synced height," the problem is the semantic gap: a user or downstream service calling getindexinfo during a -reindex-chainstate has no way to know the chainstate is at height 0 while indexes report height 850,000. This is an observable inconsistency in the API surface, even if the underlying data is not corrupted.

3. A low-cost fix exists

I'm not advocating for forcing a full index rebuild (that would be expensive and defeat the purpose of -reindex-chainstate). The minimal acceptable fix is simply a startup warning in debug.log and stdout such as:

Warning: -reindex-chainstate is rebuilding the UTXO set only. Secondary indexes (txindex, blockfilterindex, coinstatsindex) will NOT be reset and will remain at their previously synced state.

This costs nothing in terms of performance and resolves the observability gap entirely. The -help text for -reindex-chainstate should also be updated to explicitly note this behavior difference from -reindex.

Would the maintainers be open to a PR adding this warning?

you sound like an LLM (and not a particularly good one), I won't engage with that any further.

Thanks for the report, but I think this is fine as is.