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

txgraph: sort distinct-cluster chunks by equal-feerate-prefix size (feature)

Public commit record

What the developer wrote

Authored by Pieter Wuille

73/100 · Adequate
txgraph: sort distinct-cluster chunks by equal-feerate-prefix size (feature)

This makes TxGraph track the equal-feerate-prefix size of all chunks in
all clusters in the main graph, and uses it to sort chunks coming from
distinct clusters.

The order of chunks across clusters becomes:
1. Feerate (high to low)
2. Equal-feerate-prefix (small to large)
3. Cluster sequence number (old to new); this will be changed later.

The equal-feerate-prefix size of a chunk C is defined as the sum
of the weights of all chunks in the same cluster as C, with the same
feerate as C, up to and including C itself, in linearization order (but
excluding such chunks that appear after C).

This is an approximation of sorting chunks from small to large across
clusters, while remaining consistent with intra-cluster linearization
order.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit changes how Bitcoin Core's new transaction graph (TxGraph) orders groups of transactions (called 'chunks') when they have the same transaction fee rate but come from separate, unrelated clusters of transactions. It introduces a tie-breaker based on the total size of consecutive same-fee-rate chunks within a cluster. The change is described by the project as a feature improvement, not a security fix, and includes new fuzz-test checks to verify the ordering behaves consistently.

Recommended action

No security action required. Treat as a normal code-review/QA item for transaction-graph linearization correctness. Monitor downstream tests for any regressions in mempool policy or block-template construction.

Security signals we found

01

No security-relevant signals detected in commit message or diff

02

Change is explicitly framed as a feature/algorithmic improvement

03

Adds fuzz-test invariant checks and sanity assertions, which improve correctness guarantees

04

No input validation, parsing, cryptography, network, or resource-limit changes observed

Risk score

Why this scored 18/100

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