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

Consider currently confirmed FundingScope when claiming commitments

Public commit record

What the developer wrote

Authored by Wilmer Paulino

73/100 · Adequate
Consider currently confirmed FundingScope when claiming commitments

Once a commitment transaction confirms, we may have outputs to claim. To
determine whom the commitment transaction belongs to, we generally
compare its `txid` against what we know be ours and the counterparty's.
This, however, relies on being able to match on the expected
`FundingScope`, such that we can produce the necessary output claims.
Since a commitment transaction confirming implies that the funding
transaction it spends has also confirmed, we rely on
`alternative_funding_confirmed` to obtain the corresponding
`FundingScope`.
✓ 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 Dev Kit's on-chain channel monitor matches a confirmed commitment transaction to the correct funding state. Previously, the code always looked at the primary channel funding state (`self.funding`) when deciding whose commitment transaction was broadcast and which HTLCs/outputs to claim. After splicing-style channel upgrades, a commitment transaction can spend an alternative (pending) funding output. If the monitor used the wrong funding state, it could fail to recognize the commitment, miss HTLC claims, or use stale channel parameters—potentially leading to stuck funds or an inability to claim outputs during a force-close. The fix introduces a helper that selects the funding state actually confirmed on-chain.

Recommended action

Treat as a security-relevant correctness fix. Review related splicing/funding-scope logic for other places that still assume `self.funding` is authoritative. Add or extend tests covering alternative-funding commitment confirmation, revoked counterparty spends after splice, and holder commitment claims. Consider whether the new `expect`/`assert_eq!` calls are safe against maliciously crafted on-chain transactions; they appear guarded by prior funding-outpoint matching but should be fuzzed.

Security signals we found

01

Wrong-state lookup: monitor used primary `self.funding` instead of the confirmed alternative funding scope

02

Potential missed output claims during force-close/splicing

03

Potential use of stale channel parameters (e.g., channel_value_satoshis, channel_transaction_parameters) when generating claim transactions

04

New runtime assertions added to detect funding/commitment mismatches

05

Splicing-related code path (alternative_funding_confirmed / pending_funding)

06

TODO removed indicating previously incomplete handling

Risk score

Why this scored 63/100

Our methodology →
Potential impact 22/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.