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

Broadcast holder commitment for currently confirmed funding

Public commit record

What the developer wrote

Authored by Wilmer Paulino

85/100 · Strong
Broadcast holder commitment for currently confirmed funding

A `FundingScope` can only be promoted once a
`ChannelMonitorUpdateStep::RenegotiatedFundingLocked` is applied, or if
the monitor is no longer accepting updates, once the renegotiated
funding transaction is no longer under reorg risk. Because of this, our
current `FundingScope` may not reflect the latest confirmed state in the
chain. Before making a holder commitment broadcast, we must check which
`FundingScope` is currently confirmed to ensure that it can propogate
throughout the network.
✓ 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 change fixes a bug in how the Lightning node decides which commitment transaction to broadcast when a channel has gone through splicing or dual-funded RBF (i.e., the funding transaction was replaced). Previously, the node might broadcast a holder commitment tied to the wrong, no-longer-confirmed funding transaction, which could fail to claim funds or leave them exposed. The patch makes the monitor track which funding transaction is actually confirmed and uses that funding scope when generating the broadcast and related claims. It also cleans up stale claim requests when the active funding changes due to a reorg or replacement.

Recommended action

Review and merge if not already deployed. Nodes running splicing or dual-funded RBF channels should upgrade to a release containing this fix. Monitor for any related force-close behavior in production after upgrade.

Security signals we found

01

Incorrect funding scope used for holder commitment broadcast could lead to invalid or unclaimable transactions

02

Stale HTLC/claim requests from superseded funding transactions not fully canceled

03

Race between funding reorg/replacement and commitment broadcast could leave funds unclaimed

04

Dual-funded RBF and splicing scenarios explicitly mentioned as affected

05

Fix adds defensive checks, logging, and delayed broadcast to avoid conflicting commitment confirmations

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.