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

kernel: Add function to read block undo data from disk to C header

Public commit record

What the developer wrote

Authored by TheCharlatan

73/100 · Adequate
kernel: Add function to read block undo data from disk to C header

This adds functions for reading the undo data from disk with a retrieved
block tree entry. The undo data of a block contains all the spent
script pubkeys of all the transactions in a block. For ease of
understanding the undo data is renamed to spent outputs with seperate
data structures exposed for a block's and a transaction's spent outputs.

In normal operations undo data is used during re-orgs. This data might
also be useful for building external indexes, or to scan for silent
payment transactions.

Internally the block undo data contains a vector of transaction undo
data which contains a vector of the coins consumed. The coins are all
int the order of the transaction inputs of the consuming transactions.
Each coin can be used to retrieve a transaction output and in turn a
script pubkey and amount.

This translates to the three-level hierarchy the api provides: Block
spent outputs contain transaction spent outputs, which contain
individual coins. Each coin includes the associated output, the height
of the block is contained in, and whether it is from a coinbase
transaction.
✓ Specific, 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 public programming interface (API) to the Bitcoin Core 'kernel' library that lets external callers read 'undo' data—renamed here as 'spent outputs'—from disk. Undo data records which previous coins were consumed by transactions in a block. It is normally used internally during chain reorganizations, but the change exposes it for external indexing and silent-payment scanning. The change is a feature addition, not a fix for a known vulnerability, and the commit message does not describe it as security-relevant.

Recommended action

Treat as a routine feature/API expansion. Reviewers should verify that the new opaque handles and copy/destroy functions maintain correct ownership semantics, that assert-based bounds failures are acceptable for a library API, and that exposing undo data does not violate any intended isolation model for the kernel library. No immediate security patch is indicated.

Security signals we found

01

New public C API surface increases attack/exposure area for library consumers

02

Exposes previously internal undo/rev data to external callers, raising potential information-disclosure considerations if access controls are weak

03

Uses assert() for bounds checking in index accessors, which will abort the process on out-of-range access rather than returning an error

04

No input sanitization beyond existing ReadBlockUndo; relies on caller-supplied block tree entry being valid

05

No security-relevance claimed by commit message or diff

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.