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

wallet: don't delete old htlcs when we forget a channel, do it on startup.

Public commit record

What the developer wrote

Authored by Rusty Russell

100/100 · Strong
wallet: don't delete old htlcs when we forget a channel, do it on startup.

For old channels, this can take a while, and it stops everything. But
we are only doing this to save space; it's not a *functional* necessity.

A quick and dirty test with 50,000 htlcs shows the htlc deletion took
450msec. I tried adding an index, and changing it to set hstate to
HTLC_STATE_INVALID instead of deleting entries, but it still took about 350ms.

Whereas the "COUNT(*)" only took 1.7msec, so it's worth keeping.

Reported-by: @michael1011
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: lightningd: we defer deletion of old htlcs on channel close, to avoid pausing for a long time (we clean them on startup)
Fixes: https://github.com/ElementsProject/lightning/issues/7962
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This change moves a database cleanup job from the moment a channel closes to the next time the node starts up. Previously, deleting tens of thousands of old payment records when a channel closed could freeze the node for hundreds of milliseconds. Now the records are counted and reported immediately, but actually deleted later during startup. It is a performance and availability improvement, not a security fix.

Recommended action

No security action required. Treat as a normal performance/availability improvement. Operators may notice slightly faster channel closure and a small startup-time cost proportional to accumulated closed-channel htlcs.

Security signals we found

01

No security-relevant code path changed

02

Change is purely operational/performance: deferring expensive DB deletion to startup

03

No new attack surface introduced; function uses existing prepared-statement SQL binding

04

No mention of vulnerability, CVE, or security issue in commit message or diff

Risk score

Why this scored 21/100

Our methodology →
Potential impact 2/30
Exploitability 0/25
Stealth signal 1/15
Affected reach 5/15
Confidence 9/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.