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

Add UserConfig::reject_inbound_splices

Public commit record

What the developer wrote

Authored by Wilmer Paulino

58/100 · Thin
Add UserConfig::reject_inbound_splices

This option allows nodes to reject inbound channel splice requests to
ensure backwards compatibility is not broken with LDK versions < 0.2
while a splice is pending. Outbound channel splice requests (via
`ChannelManager::splice_channel`, an opt-in API) are still allowed as
users should be aware of the backwards compatibility risk prior to using
the functionality.
✓ Descriptive subject✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a new configuration option called `reject_inbound_splices` to the Lightning Dev Kit (LDK). When enabled (which is the default), a node will refuse incoming requests from other nodes to splice (resize) an existing channel. The commit also changes LDK to publicly advertise support for splicing and quiescence features, rather than only in tests. The stated purpose is to avoid breaking backwards compatibility with older LDK versions while a splice is in progress. It is a defensive, opt-in/out configuration change rather than a fix for an active vulnerability.

Recommended action

Treat as a routine feature/configuration addition, not as an emergency security patch. Operators using LDK should review the new `reject_inbound_splices` default and consider compatibility implications with peers running older LDK versions. Monitor vendor release notes for any further guidance on splicing support.

Security signals we found

01

New config flag defaults to rejecting inbound splicing

02

Backwards-compatibility concern explicitly mentioned by vendor

03

Feature bits now publicly advertise splicing/quiescence support

04

Rejection uses warning+disconnect rather than channel closure

05

No CVE, advisory, or researcher attribution present in commit

Risk score

Why this scored 29/100

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