AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 18 Bitcoin

Merge bitcoin/bitcoin#35531: txindex: hash keys and pack positions to reduce disk usage

Public commit record

What the developer wrote

Authored by merge-script

91/100 · Strong
Merge bitcoin/bitcoin#35531: txindex: hash keys and pack positions to reduce disk usage

25bed560bed370045bead21c27ea21aa228cd963 test: add forward-compat functional test for txindex (sedited)
703304ed8c19d4bc7a2bb7ff0800e5047ccc12c4 doc: add release notes for txindex disk usage and downgrading (Andrew Toth)
8e5320a2d2463131a6442f27d335c0a0f6b577fd tests: cover txindex hash prefix collisions and legacy fallback (Andrew Toth)
b75efa19ba806fbd13604a6bf67ee96a3f9eccf1 txindex: skip bloom filters and legacy lookups for new databases (Andrew Toth)
004d7c098cadecdf1915c77a95d0f856ef0c2ca5 txindex: hash key prefixes and pack block positions (Andrew Toth)
5a255970fd1b02052f669abe064ffa4d4776e40f refactor: move txindex db constants and legacy key to txindex_key.h (Andrew Toth)
327660134cb1629e31ecccb6b5a589e1e27609b2 txindex: pass the full block to DB::WriteTxs (Andrew Toth)
42771e79980cdcedd4876a168d6164c0fd26f5d2 txindex: use a new block locator for downgrade safety (Andrew Toth)
4b08baed72c4dba8d17fe68a85de459fd273d065 txindex: return optional tx and block hash from FindTx (Andrew Toth)

Pull request description:

The current txindex uses the full 32-byte txid as keys, which takes up about 66 GB of disk space today on mainnet. Using a 5-byte key prefix instead drops the disk usage to 26 GB - cutting the size to less than half.

Using the full 32-bytes is unnecessary since a 5-byte salted siphash will produce collisions in about 1 in 1.1 trillion. Some collisions will occur, but the penalty is just an extra disk read, deserialization and hash.
The tx position can be appended to the key instead of used as a value, and a LevelDB iterator can seek to the prefix and then scan for the correct tx. This is an almost identical approach to `txospenderindex`.

Also instead of storing the file position of the block, we can store only the sequence of the connected block and offset of the transaction in the block. This can be packed into a 6-byte key suffix using 3-byte representations of the sequence and offset in the block. The block file can be recovered by the CBlockIndex that is already in memory. The sequence is mapped to the block hash in the db, so we can lookup the block hash to find the CBlockIndex during reads.

If a tx is not found with this method, we fallback to looking up the legacy entry. With this method a user with an existing db can opt to erase the `indexes/txindex` folder and reindex, or keep the current index and new entries will be appended with the smaller footprint.

The time to index was faster on my machine with this method, 1h19m vs current 1h50m.
Lookups are roughly the same, around 0.2ms per lookup with `getrawtransaction`.
When testing on mainnet, I got 894,549 2-way collisions, 395 3-way collision, and 1 4-way collision that worst case could cause an extra 3 false positives when reading.

ACKs for top commit:
l0rinc:
diff reACK 25bed560bed370045bead21c27ea21aa228cd963
sedited:
ACK 25bed560bed370045bead21c27ea21aa228cd963
ajtowns:
ACK 25bed560bed370045bead21c27ea21aa228cd963

Tree-SHA512: a25c79ca7e722e2f372b65f5fc11c8b194ad49f2240b4881c7e606306aabbd3604aede3f1c33606b467486affac3a3f503638f513c896935cebbc02709cb60d8
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This is a Bitcoin Core change that makes the optional transaction index (txindex) use much less disk space by storing shortened 5-byte transaction hash prefixes and packed block positions instead of full 32-byte transaction IDs. It is a deliberate optimization, not a security fix. The code keeps backward compatibility with old-format entries and adds tests for collision handling and mixed-format lookups. There is no evidence in the commit of a vulnerability, exploit, or undisclosed security issue.

Recommended action

No security action required. Treat as a normal optimization/upgrade. Operators using -txindex who want the disk savings should follow the release notes: stop the node, delete <datadir>/indexes/txindex, and restart to rebuild. Downgrading to older releases after rebuilding will cause the index to be rebuilt in the old format.

Security signals we found

01

No security-relevant signals detected in the commit or supplied references.

02

Change is described by the project as a disk-usage optimization with backward/forward compatibility.

03

Collision handling is explicitly designed and tested: hash-prefix collisions only cause extra disk reads/deserialization, not incorrect results.

04

No CVE, advisory, security advisory, or bug-bounty attribution is present in the commit materials.

Risk score

Why this scored 18/100

Our methodology →
Potential impact 2/30
Exploitability 1/25
Stealth signal 1/15
Affected reach 2/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.