Support `maximum_pending_updates` = 0 in `MonitorUpdatingPersister`
What the developer wrote
Authored by Matt Corallo
Support `maximum_pending_updates` = 0 in `MonitorUpdatingPersister`
In the coming commits, we'll use the `MonitorUpdatingPersister` as
*the* way to do async monitor updating in the `ChainMonitor`.
However, to support folks who don't actually want a
`MonitorUpdatingPersister` in that case, we explicitly support them
setting `maximum_pending_updates` to 0, disabling all of the
update-writing behavior.
What changed, and why it matters
This is a small, intentional behavior change in a Lightning node library. It lets users set a configuration value to 0 to fully turn off a special monitor-update writing mode, making the component act like a simpler default version. The change itself is not a security fix; it is groundwork for a later feature and removes a special marker byte from saved files when the feature is disabled. There is no indication of a vulnerability being patched.
No security action required. Treat as normal code review for functional correctness of the new `maximum_pending_updates = 0` path.
Security signals we found
No security-relevant signals in commit message or diff
Change is a feature/compatability preparation, not a vulnerability fix
No mention of CVE, advisory, researcher, or exploit
Evidence from the diff
The commit modifies MonitorUpdatingPersister::new documentation and update_persisted_channel in lightning/src/util/persist.rs. It explicitly supports maximum_pending_updates = 0, which disables incremental monitor update writing. When zero, the code no longer prepends MONITOR_UPDATING_PERSISTER_PREPEND_SENTINEL to persisted monitor bytes, so the persisted data can be read directly by the standard KVStoreSync Persist implementation. This is a functional/compatability enabler, not a security patch.
Changed components
lightning/src/util/persist.rsMonitorUpdatingPersisterupdate_persisted_channel methodInspect captured patch +10 / −1
diff --git a/lightning/src/util/persist.rs b/lightning/src/util/persist.rs
index 927d199..35b4f5f 100644
--- a/lightning/src/util/persist.rs
+++ b/lightning/src/util/persist.rs
@@ -534,6 +534,10 @@ where
/// less frequent "waves."
/// - [`MonitorUpdatingPersister`] will potentially have more listing to do if you need to run
/// [`MonitorUpdatingPersister::cleanup_stale_updates`].
+ ///
+ /// Note that you can disable the update-writing entirely by setting `maximum_pending_updates`
+ /// to zero, causing this [`Persist`] implementation to behave like the blanket [`Persist`]
+ /// implementation for all [`KVStoreSync`]s.
pub fn new(
kv_store: K, logger: L, maximum_pending_updates: u64, entropy_source: ES,
signer_provider: SP, broadcaster: BI, fee_estimator: FE,
@@ -757,7 +761,12 @@ where
let mut monitor_bytes = Vec::with_capacity(
MONITOR_UPDATING_PERSISTER_PREPEND_SENTINEL.len() + monitor.serialized_length(),
);
- monitor_bytes.extend_from_slice(MONITOR_UPDATING_PERSISTER_PREPEND_SENTINEL);
+ // If `maximum_pending_updates` is zero, we aren't actually writing monitor updates at all.
+ // Thus, there's no need to add the sentinel prefix as the monitor can be read directly
+ // from disk without issue.
+ if self.maximum_pending_updates != 0 {
+ monitor_bytes.extend_from_slice(MONITOR_UPDATING_PERSISTER_PREPEND_SENTINEL);
+ }
monitor.write(&mut monitor_bytes).unwrap();
match self.kv_store.write(
CHANNEL_MONITOR_PERSISTENCE_PRIMARY_NAMESPACE,
Why this scored 19/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.