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

Automatically archive resolved `ChannelMonitor`s in the BP

Public commit record

What the developer wrote

Authored by Matt Corallo

81/100 · Strong
Automatically archive resolved `ChannelMonitor`s in the BP

When we first added auto-archiving of resolved `ChannelMonitor`s,
we wanted to be somewhat cautious of flipping it on by default as
archiving a `ChannelMonitor` too soon would be a critical bug and,
while we were confident in it, we weren't 100%. Since then its been
used extensively in various LDK deployments, including `ldk-node`.

Given its now seen substantial use, and performs an important
anti-DoS function, here we flip to calling it by default on a new
timer in `lightning-background-processor`.

Fixes #218
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This change turns on automatic cleanup of old, resolved Lightning channel monitoring data by default in LDK's background processor. Previously this cleanup existed but was not enabled by default because archiving a monitor too early could risk losing funds. After broader real-world use, the developers now enable it automatically on a timer, which helps prevent denial-of-service/resource-exhaustion issues caused by keeping stale monitors around forever. The commit itself is a defensive hardening change, not an active vulnerability fix.

Recommended action

Review as a hardening/improvement commit. Verify that archive_fully_resolved_channel_monitors correctly identifies 'fully resolved' state to avoid premature archival. Confirm the timer intervals are appropriate for your deployment. No immediate incident response is indicated by the commit content.

Security signals we found

01

Enables automatic archival of resolved ChannelMonitors, reducing long-term resource consumption and potential DoS surface from stale monitor accumulation

02

Author explicitly calls the feature an 'important anti-DoS function'

03

Author notes prior caution because premature archival would be a 'critical bug', implying correctness is safety-relevant

04

No new cryptographic, network, or trust assumptions introduced; change is a scheduling/timer integration of existing functionality

05

Adds test coverage for the archival behavior in both sync and async background processor paths

Risk score

Why this scored 36/100

Our methodology →
Potential impact 8/30
Exploitability 3/25
Stealth signal 4/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.