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

Error if the calculated v2 reserve is greater than the channel value

Public commit record

What the developer wrote

Authored by Leo Nash

85/100 · Strong
Error if the calculated v2 reserve is greater than the channel value

In 0FC channels, capping the reserve to the total value of the channel
allowed a splice initiator to withdraw past their reserve in case the
acceptor had no balance in the channel.

This is because the post-splice value of the channel was equal to the
initiator's post splice balance. Hence, this post splice balance always
matched the reserve, even though the reserve was below the dust limit.

The only thing that prevented the initiator from withdrawing all their
balance was the script dust limit check in
`interactivetxs::NegotiationContext::receive_tx_add_output`.

In case the splice acceptor had any balance in the channel, or there
were HTLCs in the channel, or the channel was not 0FC, the
splice initiator's post-splice balance was always below the full channel
value. Hence when the reserve was capped at the channel value, the
post-splice balance was always below the reserve, and the splice was
rejected.

Also, in `validate_splice_contributions`, to determine the
`counterparty_selected_channel_reserve`, we now read the holder's dust
limit from the context, instead of the current global constant.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit fixes a bug in Lightning Dev Kit's splicing logic for zero-fee-commitment (0FC) channels. Previously, when calculating the required channel reserve after a splice, the code would cap the reserve at the total channel value. In a special case where the splice acceptor had no balance and no HTLCs existed, this cap allowed the splice initiator to withdraw more than they should—effectively reducing their balance below the required reserve. The only thing stopping a full drain was a separate dust-limit check. The fix makes the reserve calculation return an error if the computed reserve would exceed the post-splice channel value, and it uses each side's actual dust limit instead of a global constant when validating splice contributions.

Recommended action

Review and merge the fix, then run the new regression tests. Consider whether any deployed nodes need to be checked for exposure to 0FC splice-out reserve bypasses. No CVE or advisory is referenced in the commit materials.

Security signals we found

01

Channel reserve bypass in 0FC splice-out

02

Reserve calculation capped to channel value instead of dust limit

03

Use of per-party dust limit rather than global constant

04

New regression test for reserve breach scenarios

05

Error propagation added to reserve computation

Risk score

Why this scored 66/100

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