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

clusterlin: pool SetInfos (preparation)

Public commit record

What the developer wrote

Authored by Pieter Wuille

58/100 · Thin
clusterlin: pool SetInfos (preparation)

This significantly changes the data structures used in SFL, based on the
observation that the DepData::top_setinfo fields are quite wasteful:
there is one per dependency (up to n^2/4), but we only ever need one per
active dependency (of which there at most n-1). In total, the number of
chunks plus the number of active dependencies is always exactly equal to
the number of transactions, so it makes sense to have a shared pool of
SetInfos, which are used for both chunks and top sets.

To that effect, introduce a separate m_set_info variable, which stores a
SetInfo per transaction. Some of these are used for chunk sets, and some
for active dependencies' top sets. Every activation transforms the
parent's chunk into the top set for the new dependency. Every
deactivation transforms the top set into the new parent chunk.

With indexes into m_set_data (SetIdx) becoming bounded by the number of
transactions, we can use a SetType to represent sets of SetIdxs.
Specifically, an m_chunk_idxs is added which contains all SetIdx
referring to chunks. This leads to a much more natural way of iterating
over chunks.

Also use this opportunity to normalize many variable names.
✓ Descriptive subject✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit is an internal refactoring of Bitcoin Core's transaction-cluster linearization code. It replaces a wasteful data structure (one 'SetInfo' per dependency) with a shared pool of SetInfos indexed separately from transactions. There is no user-facing change, no network protocol change, and no obvious security bug introduced. It is a preparation/cleanup change.

Recommended action

No security action required. Treat as routine refactoring; standard code review and regression testing are sufficient.

Security signals we found

No strong security signals were identified.

Risk score

Why this scored 14/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 0/15
Confidence 9/10
Evidence quality 5/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.