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

Enforce minimum RBF feerate from counterparty

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

68/100 · Adequate
Enforce minimum RBF feerate from counterparty

The spec's tx_init_rbf recipient requirements now mandate rejecting a
feerate below max(prev + 25 sat/kwu, ceil(prev * 25/24)), matching the
sender requirement. Previously we only enforced the 25/24 rule on
counterparties. Reuse the existing min_rbf_feerate function for both
our own and counterparty validation.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit tightens the rules a Lightning node uses when a peer tries to speed up or replace a funding transaction (an RBF attempt). Previously, the node accepted any feerate that was at least 25/24 of the previous one, even if that increase was tiny in absolute terms. The new code also requires the new feerate to be at least 25 sat/kwu higher than the previous one, matching what the protocol spec now says. This prevents a peer from getting a transaction stuck or delayed by bumping the fee by only a fraction when the absolute bump is too small to be relayed by the Bitcoin network.

Recommended action

Review and merge. The change is a straightforward spec-compliance fix that closes a validation gap. Operators should upgrade nodes that accept splicing/RBF from counterparties to ensure proposed replacement transactions are actually relayable on the Bitcoin network.

Security signals we found

01

RBF feerate validation tightened to enforce both multiplicative (25/24) and absolute (+25 sat/kwu) minimums on counterparty proposals

02

Previously accepted counterparty feerates that only satisfied the 25/24 rule are now rejected

03

Existing helper min_rbf_feerate reused for both local and remote validation, reducing code duplication and inconsistency

04

New regression tests added for low and high feerate boundary cases

05

Spec compliance change: aligns recipient requirements with tx_init_rbf sender requirements

Risk score

Why this scored 60/100

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