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

channeldb: add DeleteForwardingEvents to ForwardingLog

Public commit record

What the developer wrote

Authored by ziggie

85/100 · Strong
channeldb: add DeleteForwardingEvents to ForwardingLog

In this commit, we add a new DeleteForwardingEvents method to the
ForwardingLog that allows callers to permanently delete all forwarding
events with a timestamp at or before a specified cutoff time.

The deletion is performed in batches (default 10k, max 50k events per
transaction) to avoid holding large database locks that would block
concurrent operations. Each batch runs in its own transaction, so
other database operations can proceed between batches. Context
cancellation is checked at the start of each batch, allowing callers
to abort mid-way through a large deletion. Any batches already
committed are permanent and will not be rolled back on cancellation.

The method returns a DeleteStats struct containing the number of events
deleted and the sum of fees (AmtIn - AmtOut) earned during that period.
This allows operators to maintain aggregate financial records for
accounting purposes even after purging the detailed event history.
✓ 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 adds a new database cleanup feature to LND that lets node operators permanently delete old payment forwarding records in batches. It is a routine data-management addition, not a fix for an active security flaw. The main risk is that any bug in how it selects or deletes records could accidentally erase important financial history, but the code appears careful: it copies keys before deleting, caps batch sizes, and checks for caller cancellation between batches.

Recommended action

Treat this as a normal feature commit. Reviewers should verify that callers of DeleteForwardingEvents enforce appropriate authorization, that the end-time parameter cannot be set to a future value that would delete live records, and that the fee arithmetic (int64 cast before subtraction) cannot overflow for realistic millisatoshi amounts. No immediate security response is indicated.

Security signals we found

01

New data-destruction API added to persistent store

02

Batch deletion with caller-controlled batch size capped at 50k

03

Context-aware partial-progress semantics

04

Fee aggregation requires decoding every event before deletion

05

No authentication/authorization logic visible in this commit

Risk score

Why this scored 22/100

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