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

Wipe splice state upon failed interactive funding construction

Public commit record

What the developer wrote

Authored by Wilmer Paulino

73/100 · Adequate
Wipe splice state upon failed interactive funding construction

An interactive funding construction can be considered failed upon a
disconnect or a `tx_abort` message. So far, we've consumed the
`InteractiveTxConstructor` in the latter case, but not the former.
Additionally, we may have splice-specific state that needs to be
consumed as well to allow us to negotiate another splice later on.

This commit ensures that we properly consume all splice and interactive
funding state whenever possible upon a disconnect or `tx_abort`.

The interactive funding state is safe to consume as long as we have
either yet to reach `AwaitingSignatures`, or we have but `tx_signatures`
has not been sent/received. In all of these cases, we also make sure to
clear the quiescent state flag such that we're able to resume processing
updates on the channel.

The splice state is safe to consume as long as we don't have a pending
`FundingNegotiation::AwaitingSignatures` with a `tx_signatures`
sent/received and we don't have any negotiated candidates. Note that
until splice RBF is supported, it is not currently possible to have any
negotiated candidates with a pending interactive funding transaction.
✓ 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 state cleanup bug in the Lightning Dev Kit's handling of failed or aborted splice negotiations. Previously, if a peer disconnected during a splice negotiation, the channel could be left in a 'quiescent' (frozen) state and retain leftover splice data, preventing future splice attempts and possibly blocking normal payments. The patch ensures that when a splice fails before signatures are exchanged, all related temporary state is cleared both on disconnect and when a tx_abort message is received, and it adds tests for these scenarios.

Recommended action

Review the new reset helpers for correctness, especially the conditions under which pending_splice is fully dropped versus only funding_negotiation. Ensure the tx_abort safety path cannot be abused to force unilateral channel closes. Run the new disconnect/reload tests and consider fuzzing the splice state machine around disconnect and tx_abort boundaries.

Security signals we found

01

State cleanup bug in interactive funding / splice negotiation

02

Channel could remain quiescent after disconnect, blocking normal updates

03

Leftover pending_splice state could prevent future splice attempts

04

New safety check closes channel on tx_abort during signature exchange

05

Serialization hardened to reject non-AwaitingSignatures splice funding state on load

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.