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

Send splice_locked for promoted splice on reconnect

Public commit record

What the developer wrote

Authored by Wilmer Paulino

73/100 · Adequate
Send splice_locked for promoted splice on reconnect

When a splice confirms after our `channel_reestablish` was generated and
sent, but prior to processing the counterparty's, we may promote the
splice and clear `pending_splice`. In such cases, we're still required
to send an explicit `splice_locked` as the `channel_reestablish` we sent
did not consider the splice confirmation.
✓ 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 protocol edge case in Lightning splicing. If a splice transaction confirmed at just the wrong moment—after one peer sent a channel-reestablish message but before it received the other peer's—the node could promote the new splice funding state internally but forget to send the required follow-up 'splice_locked' message. Without that message, the counterparty would not know the splice was active on this side, potentially leaving the channel in an inconsistent or stuck state. The fix adds a fallback that sends splice_locked in that reconnect scenario, plus a regression test.

Recommended action

Review and merge the patch; ensure splice_locked is always emitted when a promoted splice's funding txid was not included in the sent channel_reestablish. Run the new regression test and consider fuzzing channel reestablish interleavings around splice confirmation.

Security signals we found

01

Protocol-state inconsistency in channel reestablishment

02

Missing required follow-up message after splice promotion

03

Race condition between splice confirmation and channel reestablish

04

Regression test added for the fixed interleaving

Risk score

Why this scored 53/100

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