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

Handle FeeRateAdjustmentError variants in splice acceptor path

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

73/100 · Adequate
Handle FeeRateAdjustmentError variants in splice acceptor path

Replace the generic error handling in splice_init and tx_init_rbf with
explicit matching on FeeRateAdjustmentError variants:

- FeeRateTooLow: initiator's feerate is below our minimum. Proceed
without contribution and preserve QuiescentAction for an RBF retry at
our preferred feerate.
- FeeRateTooHigh: initiator's feerate exceeds our maximum and would
consume too much of our change output. Reject the splice with
WarnAndDisconnect.
- FeeBufferInsufficient: our fee buffer can't cover the acceptor's
estimated fee at this feerate. Proceed without contribution.

Co-Authored-By: Claude Opus 4.6 <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 how a Lightning node responds when a peer proposes a splice or RBF transaction fee rate that is too high for the node to afford. Previously, the node would silently drop its own contribution and continue, which could let the peer push through an unexpectedly expensive transaction. Now the node explicitly rejects the splice with a warning and disconnects when the fee rate is too high, while still allowing lower or retryable cases to proceed safely.

Recommended action

Review the new variant-specific handling to ensure no other FeeRateAdjustmentError variants are silently mishandled, and confirm that WarnAndDisconnect behavior is correctly wired through the message handler. Consider whether FeeRateTooHigh should also trigger a force-close or policy-level ban in addition to disconnect.

Security signals we found

01

Explicit rejection of unaffordable fee rates in splice/RBF acceptor path

02

Replacement of generic error swallowing with variant-specific handling

03

Addition of AbortReason::FeeRateTooHigh and corresponding tx_abort behavior

04

New regression tests covering high-fee-rate rejection for both splice and RBF

05

Potential DoS vector: peer could previously force acceptor to drop contribution and continue

Risk score

Why this scored 44/100

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