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

Add support for the official splicing protocol (#2887)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

93/100 · Strong
Add support for the official splicing protocol (#2887)

We replace our experimental version of `splice_init`, `splice_ack` and
`splice_locked` by their official version. If our peer is using the
experimental feature bit, we convert our outgoing messages to use the
experimental encoding and incoming messages to the official messages.

We also change the TLV fields added to `tx_add_input`, `tx_signatures`
and `splice_locked` to match the spec version. We always write both the
official and experimental TLV to updated nodes (because the experimental
one is odd and will be ignored) but we drop the official TLV if our
peer is using the experimental feature, because it won't understand the
even TLV field.

We do the same thing for the `commit_sig` TLV. For peers who support the
official splicing version, we insert the `start_batch` message before
the batch of `commit_sig` messages.

This guarantees backwards-compatibility with peers who only support the
experimental feature.

We introduce a `retransmit_flags` field to `my_current_funding_locked`
and `next_funding` to ask our peer to retransmit `commitment_signed` or
`announcement_signatures` if we're expecting them. With this change, we
don't need to retransmit `splice_locked` on reconnection anymore to
trigger the exchange of `announcement_signatures`. We don't need to
retransmit it to let our peer know that we've seen enough confirmations
for the splice either, since `my_current_funding_locked` implies that.

This allows us to completely remove retransmission of `splice_locked` on
reconnection, and also get rid of the `your_last_funding_locked` TLV,
which greatly simplifies the reconnection logic. We do keep them for
backwards-compatibility with existing Phoenix users though, but we'll
be able to clean it up once they have updated.

Note that this works with taproot channels since we will simply provide
nonces in `channel_reestablish` when we need our peer to send
announcement signatures (not supported yet since taproot channels are
never announced).

We rollback using the `next_commitment_number` to let our peer know that
we haven't received their `commit_sig` and instead use the retransmit
flags added to the `next_funding` TLV, unless our peer is using the
legacy splicing protocol.
✓ Specific, 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 adds official Lightning channel splicing support to Eclair and replaces an experimental protocol. It includes backwards-compatibility shims for older Phoenix wallets, changes how reconnection messages request retransmission of signatures, and renumbers some protocol feature bits. The changes are broad and touch consensus-critical wire protocol and channel state logic, so bugs could affect channel safety, but the commit itself is a feature implementation rather than a clear security fix.

Recommended action

Treat this as a high-risk feature change requiring careful review and extensive interoperability testing, especially around reconnection edge cases, legacy/experimental peer compatibility, and signature retransmission. Run the updated test suite and consider fuzzing the new TLV codecs and state transitions. No immediate emergency patch is indicated from the diff alone.

Security signals we found

01

Protocol state machine changes for interactive transaction signing and reconnection retransmission

02

Backwards-compatibility shim that multiplexes two protocol versions based on peer feature bits

03

TLV type-number collision handling between official and experimental splicing protocols

04

Removal of `splice_locked` retransmission path for non-legacy peers, replaced by explicit retransmit flags

05

Changes to commitment signature retransmission logic on reconnection

Risk score

Why this scored 35/100

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