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

Defer monitor update completions after funding spend

Public commit record

What the developer wrote

Authored by Joost Jager

73/100 · Adequate
Defer monitor update completions after funding spend

When no_further_updates_allowed() is true and the persister returns
Completed, ChainMonitor now overrides the return to InProgress and
pushes a MonitorEvent::Completed directly into pending_monitor_events.
In release_pending_monitor_events, these deferred completions are
appended after per-monitor events, so ChannelManager sees the
force-close MonitorEvents before the completion.

This eliminates phantom InProgress entries that would never complete:
previously, a rejected pre-close update (e.g. commitment_signed
arriving after funding spend) returned InProgress with no completion
path, blocking MonitorUpdateCompletionActions (PaymentClaimed,
PaymentForwarded) indefinitely. A subsequent post-close update
returning Completed would then violate the in-order completion
invariant.

AI tools were used in preparing this commit.
✓ 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 an internal bug in the Lightning Dev Kit's chain monitoring code. When a channel is being force-closed (because the funding transaction was spent), the code could previously get stuck: it would report a monitor update as 'in progress' forever, blocking legitimate payment completion events like 'PaymentClaimed' or 'PaymentForwarded'. In some cases, this could also break the ordering rules for monitor updates. The fix defers the completion signal until after the force-close events are processed, allowing payments to complete normally and preventing the ordering violation. There is no direct evidence this was exploitable by an attacker; it appears to be a correctness/robustness fix.

Recommended action

Review and merge if not already merged. Run the updated regression tests and monitor for any downstream effects on event ordering in ChannelManager. Consider whether any other completion-action paths could be similarly deferred.

Security signals we found

01

Fixes invariant violation in monitor update completion ordering

02

Prevents indefinite blocking of payment completion actions (PaymentClaimed, PaymentForwarded)

03

Changes a #[should_panic] test to a passing test, indicating previously reachable panic/assertion is now avoided

04

Touches force-close and funding-spend handling paths in ChainMonitor

05

Adds debug_assert enforcing that update_monitor errors only occur post-close

Risk score

Why this scored 53/100

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