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

Add a "tx output spender" index

Public commit record

What the developer wrote

Authored by sstone

68/100 · Adequate
Add a "tx output spender" index

Adds an outpoint -> txid index, which can be used to find which transactions spent a given output.
We use a composite key with 2 parts (suggested by @romanz): hash(spent outpoint) and tx position, with an empty value.
To find the spending tx for a given outpoint, we do a prefix search (prefix being the hash of the provided outpoint), and for all keys that match this prefix
we load the tx at the position specified in the key and return it, along with the block hash, if does spend the provided outpoint.
To handle reorgs we just erase the keys computed from the removed block.

This index is extremely useful for Lightning and more generally for layer-2 protocols that rely on chains of unpublished transactions.
If enabled, this index will be used by `gettxspendingprevout` when it does not find a spending transaction in the mempool.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a new optional Bitcoin Core index called the transaction output spender index. When enabled with -txospenderindex=1, it records which transaction spent a given output, allowing the gettxspendingprevout RPC to find confirmed spending transactions, not just mempool ones. It is a feature addition, not a security fix, and does not by itself create a vulnerability. The main security-relevant consideration is that it increases disk and memory use, requires disabling pruning, and exposes more historical chain data through RPC.

Recommended action

No immediate security action required. Operators enabling -txospenderindex should be aware of increased disk, memory, and RPC data exposure. Reviewers should verify reorg correctness, cache sizing bounds, and that the index cannot be enabled with pruning.

Security signals we found

01

New optional index increases attack surface by persisting additional spend-linkability data

02

RPC gettxspendingprevout now returns full spending transactions and block hashes from confirmed chain history when index is enabled

03

Prune mode explicitly rejected when index is enabled, preventing index inconsistency

04

Uses SipHash of outpoints with a per-DB random key to mitigate preimage/key-prefix collision concerns

05

Reorg handling implemented by erasing entries from removed blocks

Risk score

Why this scored 23/100

Our methodology →
Potential impact 2/30
Exploitability 3/25
Stealth signal 2/15
Affected reach 4/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.