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

Merge PR 'Don't track refused monitor updates as pending' (#5030)

Public commit record

What the developer wrote

Authored by Matt Corallo

81/100 · Strong
Merge PR 'Don't track refused monitor updates as pending' (#5030)

from 2026-09-refused-upds-not-pending into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/5030
Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This patch fixes a bookkeeping bug in rust-lightning's ChainMonitor. When a channel monitor refuses an update (for example, because the channel is already force-closing), the code used to still record that update as 'pending completion.' Because refused updates are never later marked complete, the pending entry could sit around indefinitely and potentially block follow-up completion actions such as marking a payment as claimed. The change only adds the update to the pending list when the monitor actually accepted it.

Recommended action

Review and merge. The patch is narrowly scoped, adds regression tests, and corrects a clear state-tracking inconsistency. Operators should upgrade to a release containing this fix to avoid edge-case stalls during force-close flows with async monitor persistence.

Security signals we found

01

State inconsistency: pending monitor updates tracked for updates that will never complete

02

Potential denial of service / channel freeze: stale pending entry could block completion actions

03

Lightning-specific risk: delayed or blocked PaymentClaimed event could affect fund recovery timing

04

Defensive fix with regression test coverage for both sync and async persistence paths

Risk score

Why this scored 57/100

Our methodology →
Potential impact 18/30
Exploitability 10/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.