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

Reject RBF with non-confirming feerate after several attempts

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

85/100 · Strong
Reject RBF with non-confirming feerate after several attempts

After a few RBF attempts, both our own and the counterparty's RBF
should target a feerate that will actually confirm. Reject attempts
with feerates below the fee estimator's NonAnchorChannelFee target
to prevent exhausting the RBF budget at low feerates.

The spec requires: "MUST set a high enough feerate to ensure quick
confirmation."

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
✓ Specific, 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 change tightens the rules for fee-bumping (RBF) during Lightning channel splicing. After 10 RBF attempts, any new attempt must use a feerate high enough to actually get the transaction confirmed according to the node's own fee estimator. Before this patch, a user or counterparty could keep submitting slightly higher but still-too-low fees, draining the RBF budget without ever confirming. The patch enforces the BOLT spec requirement to 'set a high enough feerate to ensure quick confirmation.'

Recommended action

Review whether the hard-coded threshold of 10 attempts is appropriate for all network conditions and fee-estimator implementations. Ensure the fee estimator's NonAnchorChannelFee target cannot be manipulated by an attacker (e.g., via local mempool state) to force unnecessary RBF failures. Consider whether the threshold should be configurable or derived from the RBF budget.

Security signals we found

01

Denial-of-service mitigation: prevents RBF budget exhaustion via repeated low-feerate bumps

02

Spec-compliance enforcement: BOLT requirement to use a confirming feerate

03

New validation gate on counterparty RBF messages

04

New validation gate on local RBF contributions

05

Hard-coded threshold (10 attempts) before enforcing confirming feerate

Risk score

Why this scored 48/100

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