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

Handle missing splice tx_signatures on reestablish

Public commit record

What the developer wrote

Authored by Wilmer Paulino

73/100 · Adequate
Handle missing splice tx_signatures on reestablish

When reconnecting after one side has received `tx_signatures` for a
splice but the peer has not, `channel_reestablish` may need to recover
two different pieces of state: the missing `tx_signatures` and a later
commitment update generated after quiescence ended locally.

Previously the lost-remote-commitment path discarded any `tx_signatures`
prepared while processing the peer's `next_funding` TLV, as we assumed
that if a `tx_signatures` is owed, then no pending updates must exist.
That left the peer awaiting splice signatures and still treating the
channel as quiescent, so the subsequent HTLC commitment update was
rejected as a normal update while quiescent.

This was incorrect as the fuzzer highlighted that a new update can be
made after the `tx_signatures` exchange (while the counterparty has yet
to process the responding `tx_signatures`) and both messages need to be
retransmistted after a reconnect.

We fix this by carrying `tx_signatures` through that reestablish branch
and making the `tx_signatures/commitment_update` order explicit. Initial
splice funding retransmission remains
commitment_signed-before-tx_signatures, while post-splice reconnect
recovery sends tx_signatures before normal commitment updates so the
peer can exit quiescence first.
✓ 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 bug in LDK's Lightning channel reconnection logic after a splice (a way to resize a channel's on-chain funds). If one peer had already received the splice signatures but the other had not, and then they disconnected and reconnected, the recovering peer could drop its own splice signatures while trying to resend a later commitment update. That left the counterparty still waiting for splice signatures and still treating the channel as 'frozen' (quiescent), so it would reject the normal commitment update. The fix ensures both the missing splice signatures and any later commitment update are retransmitted in the correct order after reconnect.

Recommended action

Review the ordering logic in handle_channel_resumption and the new TxSignaturesOrder enum for completeness. Run the new and updated splicing reconnection tests, especially under async monitor updates, and consider fuzzing the reestablish path further. Ensure downstream nodes upgrade to include this fix to avoid channel stalls or force-closes after splice reconnects.

Security signals we found

01

Protocol-state inconsistency on reconnection after splice signature exchange

02

Potential channel stall/force-close due to quiescence not being exited before commitment update

03

Fuzzer-discovered edge case in Lightning splicing retransmission

04

New explicit ordering enum (TxSignaturesOrder) to prevent future ordering bugs

05

Test added for retransmitting completed tx_signatures during unrelated async monitor update

Risk score

Why this scored 60/100

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