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

Exit quiescence when tx_init_rbf is rejected with Abort

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

95/100 · Strong
Exit quiescence when tx_init_rbf is rejected with Abort

When tx_init_rbf is rejected with ChannelError::Abort (e.g.,
insufficient RBF feerate, negotiation in progress, feerate too high),
the error is converted to a tx_abort message but quiescence is never
exited and holding cells are never freed. This leaves the channel stuck
in a quiescent state.

Fix this by intercepting ChannelError::Abort before try_channel_entry!
in internal_tx_init_rbf, calling exit_quiescence on the channel, and
returning the error with exited_quiescence set so that handle_error
frees holding cells. Also make exit_quiescence available in non-test
builds by removing its cfg gate.

Update tests to use the proper RBF initiation flow (with tampered
feerates) so that handle_tx_abort correctly echoes the abort and exits
quiescence, rather than manually crafting tx_init_rbf messages that
leave node 0 without proper negotiation state.

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✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes a bug in the Lightning Dev Kit where a channel could get stuck in a 'quiet' state after a fee-bump (RBF) attempt is rejected. Normally, when an RBF request is rejected, the channel should resume normal operation and release any held payments. The bug left the channel frozen, which could delay or block payments. The fix ensures the channel exits the quiet state and frees held payments when an RBF rejection occurs.

Recommended action

Review and merge the patch. After deployment, monitor for any reports of channels remaining stuck in quiescence following RBF aborts. Consider backporting to stable branches if splicing/RBF is enabled in production.

Security signals we found

01

Denial-of-service-like channel stall: channel stuck in quiescent state after RBF abort

02

Resource retention: holding cells not freed, potentially blocking HTLCs/payments

03

State-machine inconsistency: quiescence not exited on abort path

04

Fix removes test-only cfg gate on exit_quiescence, indicating production relevance

Risk score

Why this scored 60/100

Our methodology →
Potential impact 20/30
Exploitability 10/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.