Hidden Bitcoin node index just got way smaller — but you’ll have to rebuild
Good news for thriftier nodes: Bitcoin Core merged a change that can shrink the optional transaction index by roughly 40 GB — but only if you rebuild it. If you just upgrade, your existing index stays as-is. Want the slimmed-down result? Plan for a rebuild.
The skinny on the new txindex
In plain terms: the txindex (the optional database that lets a node look up transactions by their full ID) now stores a much shorter lookup key. Instead of using the full 32-byte transaction ID as the database key, the new layout uses a tiny prefix derived from a salted SipHash plus a compact suffix with block/offset info. The full transaction ID is still double-checked before returning a result, so collisions are handled by verifying candidates rather than risking false matches.
One contributor rebuilt the mainnet txindex with the new format and reported a drop from about 66 GB to around 26 GB — roughly a 61% reduction for that optional index. That savings applies only to the txindex; the blockchain data and the rest of a node’s data directory aren’t included in those numbers.
Performance didn’t tank in the test. Lookups stayed snappy (about 0.2 ms in that benchmark) and the rebuild finished faster — about 1 hour 19 minutes versus 1 hour 50 minutes under the old format. Your mileage will vary depending on hardware, storage speed, chain height and software versions, but the numbers are promising.
Should you rebuild? Practical takeaways
If you keep the default upgrade path, Bitcoin Core will let you keep your existing txindex so you won’t be forced into a rebuild. That’s convenient, but it means you also keep the larger disk footprint. To actually realize the ~40 GB saving, you’ll need to recreate the index from scratch.
Heads-up on rollbacks: the compact format isn’t readable by older releases. If you rebuild the new index and then downgrade to an older Bitcoin Core release, you’ll trigger another rebuild into the old format. So plan any downgrade carefully — it comes with another time-and-space cost.
Bottom line: this is a nice, narrow win — a much smaller optional index and a quicker rebuild in at least one test. Operators who value disk space should schedule a planned index recreation once the change appears in a stable release and follow the release notes for the exact migration and downgrade steps.
