index: Delete old coinstats index directory on startup #36292

pull fjahr wants to merge 2 commits into bitcoin:master from fjahr:2026-09-coinstats-b-gone changing 3 files +16 −6

fjahr commented at 7:57 PM on September 17, 2026: contributor

coinstatsindex was updated in an incompatible way in v30 (see #30469) and moved to the indexes/coinstatsindex folder. The old indexes/coinstats directory was kept and a warning was logged so users could still downgrade to v29 without resyncing the index.

There was a TODO in the code that scheduled the deletion for v31. Since v32 branch-off has happened, this would now ship in v33. By then 29.x should be EOL assuming we are not going to release a v29.5.
index: Delete old coinstats index directory on startup 397c6c5c1c
doc: Add release note for old coinstatsindex directory deletion 82e4cc6964
DrahtBot added the label UTXO Db and Indexes on Sep 17, 2026
DrahtBot commented at 7:57 PM on September 17, 2026: contributor



The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.



Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/36292.



Reviews

See the guideline and AI policy for information on the review process.

Type Reviewers

ACK sedited

Concept ACK mzumsande

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.
mzumsande commented at 9:33 PM on September 17, 2026: contributor

Concept ACK
sedited approved
sedited commented at 8:31 AM on September 18, 2026: contributor

ACK 82e4cc6964a9a130d3a41454e046af964ea05508
DrahtBot requested review from mzumsande on Sep 18, 2026
fanquake added this to the milestone 33.0 on Sep 18, 2026
bartoli commented at 6:52 PM on September 23, 2026: none

Shouldn't deletion of the old one be done after the creation of the new one that potentially did not yet occur? The new one shouldn't need to have the old one to be created, but that 'feels' risky?
fjahr commented at 9:15 PM on September 23, 2026: contributor

Shouldn't deletion of the old one be done after the creation of the new one that potentially did not yet occur? The new one shouldn't need to have the old one to be created, but that 'feels' risky?

This isn't a concern. The new index doesn't use the old version at all. It is incompatible and has been synced from scratch since v30, so the old data is never read from there and so the order doesn't matter.