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

Store preimages we learned on chain in case of `MonitorEvent` loss

Public commit record

What the developer wrote

Authored by Matt Corallo

73/100 · Adequate
Store preimages we learned on chain in case of `MonitorEvent` loss

`MonitorEvent`s aren't delivered to the `ChannelManager` in a
durable fashion - if the `ChannelManager` fetches the pending
`MonitorEvent`s, then the `ChannelMonitor` gets persisted (i.e. due
to a block update) then the node crashes, prior to persisting the
`ChannelManager` again, the `MonitorEvent` and its effects on the
`ChannelManger` will be lost. This isn't likely in a sync persist
environment, but in an async one this could be an issue.

Note that this is only an issue for closed channels -
`MonitorEvent`s only inform the `ChannelManager` that a channel is
closed (which the `ChannelManager` will learn on startup or when it
next tries to advance the channel state), that
`ChannelMonitorUpdate` writes completed (which the `ChannelManager`
will detect on startup), or that HTLCs resolved on-chain post
closure. Of the three, only the last is problematic to lose prior
to a reload.

When we restart and, during `ChannelManager` load, see a
`ChannelMonitor` for a closed channel, we scan it for preimages
that we passed to it and re-apply those to any pending or forwarded
payments. However, we didn't scan it for preimages it learned from
transactions on-chain. In cases where a `MonitorEvent` is lost,
this can lead to a lost preimage. Here we fix it by simply tracking
preimages we learned on-chain the same way we track preimages
picked up during normal channel operation.
✓ 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 a bug in rust-lightning where a Lightning node could permanently lose a payment secret (preimage) if the node crashed at an unlucky moment after a channel was force-closed. Losing the preimage means the node cannot claim funds it is owed, effectively losing money. The fix makes the on-chain monitoring component remember preimages it learns from the blockchain, the same way it already remembers preimages learned during normal channel operation, so a restart can recover them even if an in-memory notification was lost.

Recommended action

Apply the patch. Nodes running with asynchronous persistence of ChannelManager relative to ChannelMonitor are most at risk; ensure upgrades before force-closes of channels carrying forwarded HTLCs. Review persistence ordering to minimize the window where ChannelMonitor is persisted without ChannelManager.

Security signals we found

01

Loss of payment preimage after force-close can lead to unclaimable funds

02

Crash-recovery durability gap between ChannelMonitor and ChannelManager

03

Async persistence environment increases likelihood of the race

04

On-chain learned preimage not previously retained in counterparty_fulfilled_htlcs

05

Regression test added for both counterparty and holder commitment claim paths

Risk score

Why this scored 57/100

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