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

Rework RBF and TRUC validation

Public commit record

What the developer wrote

Authored by Suhas Daftuar

90/100 · Strong
Rework RBF and TRUC validation

Calculating mempool ancestors for a new transaction should not be done until
after cluster size limits have been enforced, to limit CPU DoS potential.

Achieve this by reworking TRUC and RBF validation logic:

- TRUC policy enforcement is now done using only mempool parents of
new transactions, not all mempool ancestors (note that it's fine to calculate
ancestors of in-mempool transactions, if the number of such calls is
reasonably bounded).
- RBF replacement checks are performed earlier (which allows for checking
cluster size limits earlier, because cluster size checks cannot happen until
after all conflicts are staged for removal).
- Verifying that a new transaction doesn't conflict with an ancestor now
happens later, in AcceptSingleTransaction() rather than in PreChecks(). This
means that the test is not performed at all in AcceptMultipleTransactions(),
but in package acceptance we already disallow RBF in situations where a
package transaction has in-mempool parents.

Also to ensure that all RBF validation logic is applied in both the single
transaction and multiple transaction cases, remove the optimization that skips
the PackageMempoolChecks() in the case of a single transaction being validated
in AcceptMultipleTransactions().
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This Bitcoin Core commit reorders and reworks how two new transaction-handling features—RBF (Replace-By-Fee) and TRUC (a restricted version-3 transaction policy)—are validated. The main goal is to avoid doing expensive 'ancestor' calculations on the whole mempool until cheaper cluster-size checks have already run, so a maliciously crafted transaction can't waste a node's CPU as easily. It also makes sure the same RBF checks apply whether one transaction or a whole package is being accepted, and moves a 'spends a transaction it is replacing' check to a later, safer point.

Recommended action

Treat this as a hardening/DoS-prevention patch. Reviewers should verify that the new parent-only TRUC checks still enforce the intended 2-ancestor limit in all cases, that moving the conflict-with-ancestor check later does not create a window for inconsistent state, and that package RBF behavior is unchanged for legitimate users. Node operators should upgrade when the release containing this commit is available.

Security signals we found

01

CPU DoS mitigation: expensive ancestor calculation deferred until after cluster size limits

02

TRUC validation narrowed from full ancestors to direct parents

03

RBF checks moved earlier and unified across single/package acceptance

04

Conflict-with-ancestor check relocated to after cluster limit enforcement

05

Removal of single-tx shortcut in package RBF checks

Risk score

Why this scored 63/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 10/15
Affected reach 12/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.