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

Avoid a storage RTT when loading `ChannelMonitor`s without updates

Public commit record

What the developer wrote

Authored by Matt Corallo

85/100 · Strong
Avoid a storage RTT when loading `ChannelMonitor`s without updates

When reading `ChannelMonitor`s from a `MonitorUpdatingPersister` on
startup, we have to make sure to load any `ChannelMonitorUpdate`s
and re-apply them as well. For users of async persistence who don't
have any `ChannelMonitorUpdate`s (e.g. because they set
`maximum_pending_updates` to 0 or, in the future, we avoid
persisting updates for small `ChannelMonitor`s), this means two
round-trips to the storage backend, one to load the
`ChannelMonitor` and one to try to read the next
`ChannelMonitorUpdate` only to have it fail.

Instead, here, we use `KVStore::list` to fetch the list of stored
`ChannelMonitorUpdate`s, which for async `KVStore` users allows us
to parallelize the list of update fetching and the
`ChannelMonitor` loading itself. Then we know exactly when to stop
reading `ChannelMonitorUpdate`s, including reading none if there
are none to read. This also avoids relying on `KVStore::read`
correctly returning `NotFound` in order to correctly discover when
to stop reading `ChannelMonitorUpdate`s.
✓ 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 is a performance and robustness improvement, not a fix for an active security bug. It changes how Lightning channel monitor data is loaded on startup so that the code lists available update files first, rather than repeatedly trying to read update files until it gets a 'not found' error. This removes one round-trip to storage for users with no pending updates and makes the loader no longer depend on storage backends correctly returning a specific 'not found' error. The old behavior could, in theory, cause a node to fail to start or misload state if a storage backend returned the wrong error kind, but the commit itself does not describe any such failure being exploited.

Recommended action

Treat as a normal code-quality/performance patch. Review the new TwoFutureJoiner for soundness of the unsafe Pin handling and ensure it is only used with Unpin futures as documented. Verify that KVStore::list implementations correctly enumerate update keys and that UpdateName parsing and ordering match the prior synthetic key generation. No urgent security response is indicated by the commit content alone.

Security signals we found

01

Removes reliance on KVStore::read returning io::ErrorKind::NotFound to terminate update loading

02

Adds parallel list+read of monitor updates to avoid a storage RTT

03

Adds a new TwoFutureJoiner async primitive with unsafe Pin bypass and internal state management

04

Changes update loading from sequential speculative reads to list-then-read

Risk score

Why this scored 23/100

Our methodology →
Potential impact 4/30
Exploitability 3/25
Stealth signal 2/15
Affected reach 5/15
Confidence 6/10
Evidence quality 3/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.