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

Implement new RBF logic for cluster mempool

Public commit record

What the developer wrote

Authored by Suhas Daftuar

80/100 · Strong
Implement new RBF logic for cluster mempool

With a total ordering on mempool transactions, we are now able to calculate a
transaction's mining score at all times. Use this to improve the RBF logic:

- we no longer enforce a "no new unconfirmed parents" rule

- we now require that the mempool's feerate diagram must improve in order
to accept a replacement

- the topology restrictions for conflicts in the package rbf setting have been
eliminated

Revert the temporary change to mempool_ephemeral_dust.py that were previously
made due to RBF validation checks being reordered.

Co-authored-by: Gregory Sanders <gsanders87@gmail.com>, glozow <gloriajzhao@gmail.com>
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit rewrites how Bitcoin Core decides whether a transaction can replace existing mempool transactions via RBF (Replace-By-Fee). It removes two old rules—'no new unconfirmed inputs' and 'replacement must pay a higher per-transaction feerate than each conflict'—and replaces them with a stricter economic test: the replacement must improve the mempool's overall feerate diagram. It also changes the limit on how many transactions can be replaced from a raw count of transactions to a count of distinct transaction clusters. The change is a deliberate policy redesign, not a bug fix, and the tests are updated to match the new behavior.

Recommended action

Treat as a planned consensus-adjacent mempool policy change. Review the new feerate-diagram comparison and cluster-count limit for edge cases such as oversized clusters, prioritization deltas, and package RBF with ephemeral dust. Run the updated functional and fuzz tests. No immediate emergency response is indicated, but node operators and wallet developers should be aware that RBF acceptance semantics have changed.

Security signals we found

01

RBF policy rules relaxed: new unconfirmed inputs now allowed

02

RBF policy rules tightened: replacement must improve mempool feerate diagram

03

Replacement candidate limit changed from transaction count to cluster count

04

Removal of per-conflict feerate comparison (Rule #6)

05

Removal of topology restrictions for package RBF conflicts

06

New dependency on cluster mempool total ordering and TxGraph diagram calculation

Risk score

Why this scored 35/100

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