Transaction Index (txindex)

The transaction index, enabled with -txindex=1, is an optional LevelDB database that records where every transaction lives inside the block files on disk. By default Bitcoin Core only indexes blocks and the unspent-output set, so it can validate the chain and track your own coins without ever needing to find an arbitrary historical transaction by its ID. The txindex adds that capability: with it built, a node can answer getrawtransaction for any transaction ever confirmed, not just unspent or wallet-relevant ones.

Why Core doesn't index everything by default

It surprises many newcomers that a full node cannot, out of the box, look up an arbitrary old transaction. The reason is a deliberate design principle: validation does not require it. Consensus only ever needs to know whether an output is currently spendable, which the compact UTXO set answers directly. Keeping historical transactions addressable by ID is a convenience for humans and applications, not a requirement of the protocol — so Core makes it opt-in and spends nothing on it for the majority of nodes that never need it.

What it stores and where

The index lives at indexes/txindex/ and maps each transaction ID to the block file and byte offset where that transaction is stored. It does not duplicate transaction data; it is a pointer table over the existing blk*.dat files. Building it requires reading the whole chain once — an extra pass after initial block download — and adds several gigabytes of disk. It builds in the background while the node runs, and thereafter maintains itself with each new block. Note that txindex is unavailable on a pruned node, because pruning deletes the old block files the index would point into; this is one of the classic reasons node runners choose an unpruned archive node.

Who needs it

Block explorers, accounting and analytics tools, Lightning implementations that look up funding transactions, and Electrum-style personal servers generally require txindex, because they must resolve transactions outside any single wallet's view. If you self-host a stack like a personal block explorer or an Electrum server for your hardware wallet, txindex is almost always on the prerequisite list. A node that simply validates and guards your own coins does not need it — the wallet already tracks its own transactions, and getrawtransaction works without txindex for anything still in the mempool or when you can tell it which block to look in.

Practical guidance

A note on lifecycle: the index can be turned off later, and the space reclaimed, without harming the node — it is a pure derivative of the block files and can always be rebuilt. That makes txindex a low-regret experiment: enable it when a project needs it, drop it when the project ends. The one-way doors in node configuration are elsewhere (pruning discards data that cannot be recovered without a resync); txindex is merely a lookup table, and lookup tables are cheap to regret. Budget the rebuild time on your hardware — hours on fast storage, longer on spinning disks — and flip the flag whenever the need actually arrives.

The decision is easiest made before initial sync, since enabling txindex later triggers the historical build over the whole chain — not harmful, just slow on modest hardware. Disk is the real budget line: an archival node with txindex wants comfortable headroom above the raw blockchain size. If your goal is a private wallet backend rather than general transaction lookup, compare what you actually need against the block filter index, which serves light clients privately, and the coinstats index, which answers supply and UTXO-set statistics. Each index answers a different question; a sovereign node runner enables the ones their stack asks, and no more.