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

Handle mon update completion actions even with update(s) is blocked

Public commit record

What the developer wrote

Authored by Matt Corallo

85/100 · Strong
Handle mon update completion actions even with update(s) is blocked

If we complete a `ChannelMonitorUpdate` persistence but there are
blocked `ChannelMonitorUpdate`s in the channel, we'll skip all the
post-monitor-update logic entirely. While its correct that we can't
resume the channel (as it expected the monitor updates it generated
to complete, even if they ended up blocked), the post-update
actions are a `channelmanager.rs` concept - they cannot be tied to
blocked updates because `channelmanager.rs` doesn't even see
blocked updates.

This can lead to a channel getting stuck waiting on itself. In a
production environment, an LDK user saw a case where:
(a) an MPP payment was received over several channels, let's call
them A + B.
(b) channel B got into `AwaitingRAA` due to unrelated operations,
(c) the MPP payment was claimed, with async monitor updating,
(d) the `revoke_and_ack` we were waiting on was delivered, but the
resulting `ChannelMonitorUpdate` was blocked due to the
pending claim having inserted an RAA-blocking action,
(e) the preimage `ChannelMonitorUpdate` generated for channel B
completed persistence, which did nothing due to the blocked
`ChannelMonitorUpdate`.
(f) the `Event::PaymentClaimed` event was handled but it, too,
failed to unblock the channel.

Instead, here, we simply process post-update actions when an update
completes, even if there are pending blocked updates. We do not
fully unblock the channel, of course.
✓ 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 commit fixes a bug in the Lightning Dev Kit (LDK) where a channel could get stuck waiting on itself after a multi-path payment (MPP) was claimed. Previously, when a monitor update completed but another monitor update was blocked, LDK skipped important follow-up actions, such as emitting the PaymentClaimed event and releasing held HTLCs. The fix ensures these follow-up actions run even when the channel still has blocked monitor updates, preventing channels from hanging.

Recommended action

Review and merge the patch. Users running LDK nodes, especially those using async monitor persistence and MPP, should upgrade to avoid channel-stall scenarios. No immediate external mitigation is described.

Security signals we found

01

Denial-of-service-like channel stall in multi-path payment claiming

02

Incorrect state machine handling of blocked ChannelMonitorUpdates

03

Missing post-monitor-update completion actions when updates are blocked

04

Regression test added for MPP claim with async monitor updates and blocked RAA

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.