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

Send `splice_locked` if necessary while reconnecting (#3318)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

81/100 · Strong
Send `splice_locked` if necessary while reconnecting (#3318)

When we lock a commitment while reconnecting, we currently have a bug
where if we've sent our `channel_reestablish` but we haven't received
the remote `channel_reestablish`, we will not send `splice_locked`
which results in a mismatch in the expected number of `commit_sig`
messages for our peer, triggering a force-close.

We now send `splice_locked` when we are in the `SYNCING` state when
that makes sense. The logic is very similar to the `NORMAL` state,
but we don't emit events that are meant to be used when the channel
is ready to handle payments.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit fixes a bug in Eclair, a Bitcoin Lightning Network node implementation. During reconnection after a splice (a way to resize a payment channel), if a funding transaction became confirmed at a specific moment, the node would fail to notify its peer. That missing notification caused the peer to expect a different number of signature messages, leading both sides to force-close the channel and settle on the blockchain. The fix makes the node send the required `splice_locked` message even while it is still synchronizing with the peer. It is a bug fix, not an exploit by an attacker, but it could be triggered by normal network timing.

Recommended action

Apply the patch and run the new regression test. Operators should upgrade nodes that handle splicing to avoid unnecessary force-closes during reconnections. No immediate incident response is required because the issue is a protocol bug rather than an externally exploitable vulnerability.

Security signals we found

01

State-machine bug in channel reconnection handshake

02

Missing protocol message (`splice_locked`) during `SYNCING` state

03

Can lead to unwanted channel force-close and on-chain settlement

04

Refactor of existing handlers to cover additional FSM state

05

Regression test added for the reconnecting splice-locking scenario

Risk score

Why this scored 55/100

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