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

Enforce `min_funding_satoshis` after splices

Public commit record

What the developer wrote

Authored by Leo Nash

68/100 · Adequate
Enforce `min_funding_satoshis` after splices

In inbound channels, we already enforce this minimum at channel open, so
it makes sense to also enforce this minimum on any splices in which the
counterparty's contribution is negative.

Codex wrote the tests.
✓ Descriptive subject✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes a consistency gap in the Lightning Dev Kit: a setting that normally blocks very small inbound channels when they are first opened was not being checked after a 'splice' that shrinks the channel. A splice lets both parties add or remove funds from an existing channel without closing it. The change now applies the same minimum-channel-size rule to inbound splices where the other side is taking money out, preventing the channel from becoming smaller than the node operator allowed. The patch is defensive and adds tests, but it is narrowly scoped to one configuration check.

Recommended action

Review whether any other handshake limits (e.g., max funding, max HTLC in-flight, channel reserve rules) are similarly bypassed by splice paths. Consider whether the check should also apply to outbound channels or to all splices, not only those with a negative counterparty contribution. The current patch is a targeted fix and should be backported if the affected release branch supports splicing.

Security signals we found

01

Missing authorization/policy enforcement: an existing inbound-channel policy (`min_funding_satoshis`) was not enforced after splice operations that reduce channel capacity.

02

Defensive hardening: the patch closes the gap by re-applying the configured minimum to splice-in/splice-out/RBF flows where the counterparty removes funds.

03

Peer-disconnect on violation: failures are surfaced as `WarnAndDisconnect`, terminating the offending peer's connection.

04

Test coverage: six new unit tests assert the new behavior for both accepted and rejected cases across splice message types.

Risk score

Why this scored 52/100

Our methodology →
Potential impact 12/30
Exploitability 10/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.