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

Detect commitment transaction confirmation in ChannelMonitor instead

Public commit record

What the developer wrote

Authored by Wilmer Paulino

83/100 · Strong
Detect commitment transaction confirmation in ChannelMonitor instead

Previously, the `ChannelManager` would assume a `Channel` was closed the
moment it saw a spend for its funding input. With splicing, this will no
longer be the case. Since the `ChannelMonitor` is already responsible
for reliably tracking each onchain transaction relevant to a channel, we
now produce a `MonitorEvent::CommitmentTxConfirmed` event to inform the
`ChannelManager` the channel can be considered closed and removed.

As a result of this change, many tests failed now that we rely on
handling the `MonitorEvent::CommitmentTxConfirmed` first before seeing
the `ChannelMonitorUpdateStep::ChannelForceClosed` go out.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit moves the responsibility for detecting when a channel-closing transaction has been confirmed from the ChannelManager to the ChannelMonitor. This is a preparatory architectural change for splicing, where a spend of the funding output does not necessarily mean the channel is closed. The change introduces a new MonitorEvent::CommitmentTxConfirmed event so the ChannelMonitor can reliably inform the ChannelManager when to actually close and remove a channel. Most of the diff is test updates adjusting the order in which closure-related events and monitor updates are expected.

Recommended action

Review as a normal refactor/preparatory change. Verify that ChannelMonitor reliably emits CommitmentTxConfirmed in all closure paths and that ChannelManager handles the event atomically with respect to monitor updates. No immediate security patch action is indicated by the diff alone.

Security signals we found

01

Architectural change in on-chain channel closure detection

02

New MonitorEvent::CommitmentTxConfirmed event introduced and serialized

03

ChannelManager no longer assumes closure on any funding-input spend

04

Test assertions reordered to match new monitor-driven closure event ordering

05

One test now expects HolderForceClosed instead of CommitmentTxConfirmed for a monitor-initiated broadcast path

Risk score

Why this scored 34/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 4/15
Affected reach 6/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.