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

Reject `splice_init`s when we aren't quiescent

Public commit record

What the developer wrote

Authored by Matt Corallo

45/100 · Thin
Reject `splice_init`s when we aren't quiescent
✓ Descriptive subject✓ Names a concrete action or component! No meaningful explanatory body
The short version

What changed, and why it matters

This commit adds a safety check in the Lightning Dev Kit's channel code to refuse splice-in operations unless the channel is in a quiet, stable state called 'quiescent.' Before this change, the code apparently allowed splice initiation even when the channel was busy with other activity. The patch prevents potential protocol confusion or unsafe splice handling by disconnecting the peer with a warning if a splice is requested at the wrong time.

Recommended action

Treat as a protocol-hardening fix. Review whether other splice-related message handlers (splice_ack, splice_locked, tx_add_input, etc.) also enforce quiescence and other required preconditions consistently. Consider adding regression tests for splice_init during non-quiescent states.

Security signals we found

01

Missing state-guard check in protocol message handler

02

Enforcement of quiescence precondition for splice operations

03

Use of WarnAndDisconnect to reject invalid peer request

Risk score

Why this scored 50/100

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