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

Avoid resetting splice state on FundingNegotiation::AwaitingSignatures

Public commit record

What the developer wrote

Authored by Wilmer Paulino

85/100 · Strong
Avoid resetting splice state on FundingNegotiation::AwaitingSignatures

Otherwise, we won't ever be able to resume a pending negotiation after a
reconnection via `channel_reestablish`.

Along the way, we also merge `should_reset_pending_splice_state` into
`PendingFunding::can_abandon_state` to simplify the logic around when
we're able to reset specific parts of the pending splice state.
✓ 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 commit fixes a bug in how the Lightning Dev Kit handles interrupted splice negotiations. Previously, if a splice negotiation reached the 'AwaitingSignatures' stage and the connection dropped, the node would incorrectly reset its splice state on reconnection. That prevented the channel from ever resuming the pending splice negotiation via the standard channel_reestablish flow. The fix stops the reset in that specific stage and simplifies the related state-cleanup logic. It is a protocol-correctness fix rather than a direct theft-of-funds vulnerability, but it could cause channels to become stuck or force unnecessary closures.

Recommended action

Review the new state-machine transitions for FundingNegotiation and verify that AwaitingSignatures is preserved across disconnect/reconnect in both directions. Run the updated splicing_tests and add coverage for the AwaitingSignatures reconnection case if not already present. Consider whether any nodes already running the buggy code need migration guidance for stuck splice states.

Security signals we found

01

State-machine bug in splice negotiation lifecycle

02

Incorrect reset of pending splice state on reconnection

03

Potential channel stall or forced close after reconnection

04

Protocol-correctness fix for channel_reestablish handling

Risk score

Why this scored 33/100

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