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

Support accepting splice-out

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

58/100 · Thin
Support accepting splice-out

When a counterparty sends splice_init with a negative contribution, they
are requesting to remove funds from a channel. Remove conditions
guarding against this and check that they have enough channel balance to
cover the removed funds.
✓ Descriptive subject✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds support for 'splice-out', a way for a Lightning channel partner to remove funds from an existing channel rather than only adding funds. Previously, the code rejected negative contribution values outright. The change removes that blanket rejection and adds checks to ensure the counterparty actually has enough balance in the channel to cover the requested withdrawal. It also centralizes validation of the counterparty's splice contribution in a new helper function used in both incoming and outgoing splice paths.

Recommended action

Review the new validate_splice_contribution logic for off-by-one and unit-conversion issues, especially the conversion from msat to sat for the counterparty's channel balance. Ensure the pending TODO for channel reserve enforcement is completed before splicing is enabled in production, as missing reserve checks could allow a counterparty to push a channel below its reserve requirement. Consider adding tests covering negative contribution edge cases, overflow scenarios, and reserve violations.

Security signals we found

01

Previously rejected negative splice contributions are now accepted, changing the attack surface

02

New balance-solvency check attempts to prevent splicing out more than the counterparty owns

03

Missing channel reserve check is explicitly acknowledged in a TODO

04

Validation logic is refactored into a shared helper to reduce duplicated checks

05

Both splice-in and splice-out paths now share the same MAX_MONEY bounds checks

Risk score

Why this scored 42/100

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