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

Allow stale `ChannelMonitor`s if we are sure they don't have funds

Public commit record

What the developer wrote

Authored by Matt Corallo

73/100 · Adequate
Allow stale `ChannelMonitor`s if we are sure they don't have funds

In 601bf4bd8fdc37d55e571b1b3b9011a1c107afd9 we started refusing to
load `ChannelMonitor`s which were created prior to LDK 0.0.110 and
which were last updated prior to LDK 0.0.119. While this is likely
fine for nearly all of our users, there's some risk that some (like
me) have ancient un-archived `ChannelMonitor`s.

We do need to start auto-archiving `ChannelMonitor`s but for now we
need some way for such users to at least not fail on startup.
Sadly, ancient `ChannelMonitor`s often don't contain some of the
data we need to accurately calculate `Balance`s, but in cases where
they do, and where there are no claimable `Balance`s, we can be
confident we don't need the `ChannelMonitor`s.

Thus, here, we adapt the `ChannelMonitor` `Readable` implementation
used in the persistence wrappers to detect this case and simply
skip loading such `ChannelMonitor`s. Its not clear if this is
sufficient, but its at least better than the current state of
affairs after 601bf4bd8fdc37d55e571b1b3b9011a1c107afd9.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit changes how an old Bitcoin Lightning wallet library (LDK) loads very old channel backup files called ChannelMonitors. Previously, if a backup was too old, the program would crash on startup. Now, if the backup is old but appears to contain no remaining funds, the program silently skips loading it instead of crashing. This is intended as a safety valve for users with ancient backups, but it also means old backups that might still matter could be ignored if the 'no funds' check is wrong.

Recommended action

Review whether the balance-empty check is sufficient to guarantee no funds remain, especially for edge cases involving pending HTLCs, revoked commitments, or reorgs. Ensure users are warned when a monitor is skipped rather than silently dropping it. Consider adding metrics or logging at the persistence layer. Complete the TODO to auto-archive or clean up stale monitors rather than leaving them in storage.

Security signals we found

01

Behavioral change from fail-closed (panic/error) to fail-open (skip) for stale ChannelMonitors

02

Use of a dummy public key (from [2;33]) for counterparty_node_id when real value is absent

03

Conditional skip based on get_claimable_balances().is_empty() and on-chain state flags

04

Persistence wrappers now silently drop unloadsable monitors instead of aborting startup

05

TODO comment indicates future auto-archiving is still needed

Risk score

Why this scored 46/100

Our methodology →
Potential impact 12/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.