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

Adjust contribution feerate to minimum RBF feerate in funding_contributed

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

73/100 · Adequate
Adjust contribution feerate to minimum RBF feerate in funding_contributed

When splice_channel is called before a counterparty's splice exists, the
user builds a contribution at their chosen feerate without a minimum RBF feerate.
If the counterparty completes a splice before funding_contributed is
called, the contribution's feerate may be below the 25/24 RBF
requirement. Rather than always waiting for the pending splice to lock
(which would proceed as a fresh splice), funding_contributed now attempts
to adjust the contribution's feerate upward to the minimum RBF feerate when the
budget allows, enabling an immediate RBF.

When the adjustment isn't possible (max_feerate too low or insufficient
fee buffer), the contribution is left unchanged and try_send_stfu delays
until the pending splice locks, at which point the splice proceeds at the
original feerate.

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
The short version

What changed, and why it matters

This commit fixes a protocol edge case in Lightning splicing. If a user prepared a splice contribution at a low fee rate, and meanwhile the other party completed their own splice, the user's contribution might no longer satisfy Bitcoin's RBF (Replace-By-Fee) minimum-bump rule. The patch makes the node automatically raise its contribution's fee rate when the budget allows, so the splice can proceed immediately as an RBF instead of stalling or falling back to a fresh splice. If the budget doesn't allow it, the node gracefully waits instead of sending an invalid message.

Recommended action

Reviewers should verify that the initiator/acceptor fee responsibility split in compute_feerate_adjustment matches the protocol spec, confirm no regression in the acceptor path, and consider whether logging is sufficient for operators to understand when a splice is delayed versus adjusted.

Security signals we found

01

Fixes a protocol compliance issue where a splice contribution could be below the minimum RBF feerate (25/24 rule)

02

Prevents sending STFU/TxInitRBF with a feerate that would violate RBF requirements

03

Adds graceful fallback to fresh splice when adjustment is impossible

04

Refactors fee estimation to correctly assign common/shared transaction weight to the initiator

05

Adds unit and integration tests covering adjustment, max-feerate rejection, and insufficient budget

Risk score

Why this scored 34/100

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