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

Run existing validation code against the candidate funding scope

Public commit record

What the developer wrote

Authored by Leo Nash

73/100 · Adequate
Run existing validation code against the candidate funding scope

As a result, we now validate that both commitments retain at least one
output under the new funding scope, which is crucial for zero-reserve
channels.
✓ 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 validation when Lightning channels are re-funded or 'spliced.' Previously, some checks used rough estimates and debug-only assertions; now the code builds a realistic candidate funding state and runs the same balance/reserve checks against it. The key fix is ensuring that after a splice, both sides' commitment transactions still have at least one output, which matters for zero-reserve channels. Without this, a malicious or malformed splice proposal could potentially reduce a party's balance so low that their commitment transaction becomes empty or invalid, risking loss of funds or channel failure.

Recommended action

Treat this as a security-hardening fix for the splicing code path. Reviewers should verify that the new candidate-scope validation covers all splice variants (inbound, outbound, RBF, interactive), and that the 'at least one output' check is enforced on both commitments in production builds, not only under debug_assertions. Consider adding regression tests for zero-reserve splice scenarios where one party's balance would drop below the dust threshold.

Security signals we found

01

Replaced debug_assert-based validation with explicit Result-returning error checks in FundingScope::for_splice

02

Removed compute_post_splice_value, which used saturating_add and could hide overflow

03

validate_splice_contributions now validates against a constructed candidate FundingScope rather than current balances

04

get_holder_counterparty_balances_floor_incl_fee now checks both local and remote commitments have at least one output, relevant for zero-reserve channels

05

All splice/RBF entry points now route through the unified validation path

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.