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

Support persistent monitor events

Public commit record

What the developer wrote

Authored by Valentine Wallace

68/100 · Adequate
Support persistent monitor events

Currently, the resolution of HTLCs (and decisions on when HTLCs can be
forwarded) is the responsibility of Channel objects (a part of ChannelManager)
until the channel is closed, and then the ChannelMonitor thereafter. This leads
to some complexity around race conditions for HTLCs right around channel
closure. Additionally, there is lots of complexity reconstructing the state of
all HTLCs in the ChannelManager deserialization/loading logic.

Instead, we want to do all resolution in ChannelMonitors (in response to
ChannelMonitorUpdates) and pass them back to ChannelManager in the form of
MonitorEvents (similar to how HTLCs are resolved after channels are closed). In
order to have reliable resolution, we'll need to keep MonitorEvents around in
the ChannelMonitor until the ChannelManager has finished processing them. This
will simplify things - on restart instead of examining the set of HTLCs in
monitors we can simply replay all the pending MonitorEvents.

Here we complete work that was built on recent prior commits and actually start
re-providing monitor events on startup if they went un-acked during runtime. We
also remove a test that explicitly relied on the old non-persistent behavior.
✓ Descriptive subject✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit makes HTLC resolution events durable in the ChannelMonitor so they survive restarts. Previously, if a ChannelMonitor was persisted but the ChannelManager crashed before persisting, monitor events could be lost, potentially causing payment failures or funds to be stuck. The fix adds an acknowledgment mechanism: events are retained until the ChannelManager explicitly acks them, and unacked events are replayed on startup. A large test that verified the old, lossy behavior was removed.

Recommended action

Review the new ack_monitor_event contract in chain::Watch implementations to ensure events are acknowledged promptly and durably. Verify that no custom Watch implementation drops events without acking, as that would now cause repeated replays. Confirm serialization round-trips preserve event IDs correctly.

Security signals we found

01

Durability fix for HTLC resolution events across restarts

02

New acknowledgment API for monitor events

03

Removal of test for previously lossy behavior

04

Prevents potential loss of PaymentFailed events after async persistence crashes

05

Changes to serialization/deserialization of pending monitor events

Risk score

Why this scored 52/100

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