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

Handle inferred splice_locked on reestablish first prior to updates

Public commit record

What the developer wrote

Authored by Wilmer Paulino

83/100 · Strong
Handle inferred splice_locked on reestablish first prior to updates

Upon channel reestablishment, we free our holding cells to send any
pending updates to our peer. If we happened to implicitly lock a pending
splice during reestablishment, we want to make sure any updates we send
after the fact are considering the new channel state (post-splice), even
if the update was queued while the splice was still pending. Therefore,
we must always handle the inferred `splice_locked` first.

Found by the `chanmon_consistency` fuzz target.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes an ordering bug in LDK's Lightning channel reconnection logic. When two peers reconnect after a channel splice (a way to resize a Lightning channel), LDK can infer that the splice has finalized even if the explicit 'splice_locked' message was missed. Previously, LDK would release queued payment updates before applying that inferred splice, which could cause it to generate commitment transactions based on the old channel state. The fix applies the inferred splice first, then releases queued updates. The bug was found by an internal fuzz test, not reported as an external security issue.

Recommended action

Review and merge the patch, then run the splicing and channel monitor consistency test suites. Operators running LDK nodes with splicing enabled should upgrade to a release containing this fix to avoid potential commitment state inconsistency after reconnections.

Security signals we found

01

State ordering bug: pending commitment updates could be generated against pre-splice channel state

02

Inferred splice_locked not applied before freeing holding cells

03

Potential for stale commitment signatures or inconsistent channel state after reconnection

04

Regression test demonstrates claim held until monitor update completes

05

Found by internal chanmon_consistency fuzz target, not an external report

Risk score

Why this scored 59/100

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