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

Validate `next_splice_out_maximum_sat` on both commitments

Public commit record

What the developer wrote

Authored by Leo Nash

73/100 · Adequate
Validate `next_splice_out_maximum_sat` on both commitments

Wilmer's fuzzing runs caught a case where an advertised splice out
maximum hit the debug assertions in `get_next_splice_out_maximum`.
These debug assertions ensure that any adverstised splice out maximum
passes the validation of splice contributions.

The core issue is that we only read the local commitment when
calculating the splice out maximum, but our splice validation requires
that any splice out maximum is covered by the minimum of the holder's
balances on the local and the remote commitments.

Therefore, if a HTLC is dust on the local commitment, but non-dust on
the remote commitment, and the holder is the funder of the channel, we
advertise a splice out maximum that is not covered by the holder's
balance on the remote commitment, and fails our validation of splice
contributions.

We now read both commitments when calculating the next splice out
maximum, which fixes this issue.
✓ 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 how the Lightning node calculates the maximum amount a user can splice out of a channel. Previously, the calculation only looked at the user's own view of the channel (the local commitment). It now also checks the peer's view (the remote commitment). If the two views differ because an HTLC is considered 'dust' (too small to be worth including as an output) on one side but not the other, the old code could advertise a splice-out limit that the node's own safety rules would later reject. In debug builds this triggered an internal assertion failure; in release builds it could lead to inconsistent or rejected splice attempts. The fix makes the advertised limit valid under both commitments.

Recommended action

Apply the patch. It is a targeted correctness fix for splicing logic and includes regression tests. Nodes that do not use splicing are not affected. Review any custom splicing integrations to ensure they do not rely on the previous single-commitment behavior.

Security signals we found

01

Invariant violation in splice-out maximum calculation

02

Debug assertion failure triggered by fuzzing

03

Channel state inconsistency between local and remote commitments

04

Dust/non-dust HTLC asymmetry across commitments

05

Potential denial of service via malformed or edge-case splice negotiation

Risk score

Why this scored 59/100

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