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

splice: Update to current spec

Public commit record

What the developer wrote

Authored by Dusty Daemon

88/100 · Strong
splice: Update to current spec

Updating splice related reestablish code to
https://github.com/lightning/bolts/pull/1289
and
https://github.com/lightning/bolts/pull/1160

Changelog-Changed: Breaking change -- if you have splicing enabled on a channel both nodes must upgrade in unison due to updating `channel_reestablish` for to new splice specifications
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit updates Core Lightning's implementation of the Lightning protocol's 'splicing' feature to match a newer draft specification. It changes the format of the channel_reestablish message used when two nodes reconnect after a disconnection. The changelog calls this a breaking change: both nodes in a channel must upgrade together if splicing is enabled, or they may fail to reconnect or misunderstand each other's state. The changes are primarily protocol-compliance and interoperability fixes rather than a clear security patch, but they affect how nodes agree on which funding transaction is active after a splice.

Recommended action

Treat this as a protocol-breaking update rather than an urgent security fix. Operators using experimental splicing should upgrade both channel peers together to avoid reconnection failures or state mismatches. Reviewers should verify that the new `implied_peer_splice_locked` path cannot be triggered by a stale or replayed `channel_reestablish` in a way that advances splice state prematurely, and that the `retransmit_flags` bitfield is parsed and validated correctly against malformed peer messages.

Security signals we found

01

Breaking protocol change in channel reestablish TLV format

02

Removal of `your_last_funding_locked_txid` and restructuring of funding-locked fields

03

Addition of `retransmit_flags` bitfield controlling post-reconnection signature retransmission

04

New implied splice_locked processing path triggered by `my_current_funding_locked` on reconnection

05

Changelog-Changed explicitly warns both nodes must upgrade together when splicing is enabled

Risk score

Why this scored 32/100

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