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

Check v2 reserves after `funding_contribution_satoshis` is applied

Public commit record

What the developer wrote

Authored by Leo Nash

73/100 · Adequate
Check v2 reserves after `funding_contribution_satoshis` is applied

We check this when validating `splice_init`, `splice_ack` messages, and
also when validating user-specified contributions.

From BOLT 2:
```
- If `funding_contribution_satoshis` is negative and its absolute value
is greater than the sending node's current channel balance:
- MUST send a `warning` and close the connection or send an `error`
and fail the channel.
```

and further down:
```
If a side does not meet the reserve requirements, that's OK: but if they
take funds out of the channel, they must ensure that they do meet them.
If your peer adds a massive amount to the channel, then you only have
to add more reserve if you want to contribute to the splice (and you
can use `tx_remove_output` and/or `tx_remove_input` part-way through if
this happens).
```

Therefore, we check the v2 reserve anytime
`funding_contribution_satoshis` is not equal to zero.

We allow parties to draw from their previous reserve, as long as they
satisfy their v2 reserve.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit tightens the rules for Lightning channel splicing (a way to add or remove funds from an existing channel). It makes sure that after a splice, each side still has enough money left in the channel to meet the required 'channel reserve'—a safety buffer meant to discourage cheating. Before this change, the code did not fully enforce that reserve check when a splice removed funds, which could have let one party drain too much money and leave the channel in a risky state. The patch also cleans up overflow checks and fee handling.

Recommended action

Review the new reserve calculations for off-by-one and rounding issues, especially the conversion from millisatoshis to satoshis. Ensure test coverage exists for splice-out that reduces a balance exactly to the reserve, and for counterparty-initiated splice with negative contributions. Consider whether the dust_exposure_limiting_feerate workaround could affect balance floor estimates.

Security signals we found

01

Missing reserve enforcement during splicing could allow a party to reduce its balance below the protocol-required reserve

02

BOLT 2 reserve requirement now checked whenever funding_contribution_satoshis is non-zero

03

Integer overflow/underflow protection added for contribution and fee arithmetic

04

Consolidated validation for both local-initiated and counterparty-initiated splice messages

05

Splice-out fee handling changed to add fees on top of user-specified contribution

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.