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

routerrpc: implement DeleteForwardingHistory RPC handler

Public commit record

What the developer wrote

Authored by ziggie

95/100 · Strong
routerrpc: implement DeleteForwardingHistory RPC handler

In this commit, we implement the server-side handler for the
DeleteForwardingHistory RPC, connecting the proto definition to the
database layer through the ForwardingLogDB interface on RouterBackend.

The handler resolves the time specification from the request oneof: an
absolute Unix timestamp is used directly, while a relative duration
string is parsed via parseDuration and resolved against the current
clock time. We use the injected clock (RouterBackend.Clock) rather than
time.Now to keep the handler testable.

A configurable minimum age guard (MinFwdHistoryAge, defaulting to 1h)
prevents accidental deletion of recent events. The minimum age can be
overridden via --routerrpc.min-fwd-history-age for environments such as
integration tests that need a shorter threshold.

The context is threaded through to DeleteForwardingEvents so that client
cancellation or deadline expiry aborts the deletion between batches.
Batches already committed at cancellation time are permanent, but the
operation is safe to re-run since deletion is idempotent.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit adds a new RPC command that lets an authenticated user permanently delete old Lightning Network forwarding records from the database. It includes safety guards: the cutoff time must not be before 1970, and it must be at least one hour in the past (or a dev/test override). The change is mostly defensive, but it introduces a powerful deletion capability that could be abused by anyone who steals the right admin/macaroon credentials or exploits a caller with that permission.

Recommended action

Review macaroon scope and access controls for the new offchain:write action; ensure only intended privileged callers can invoke DeleteForwardingHistory. Verify the minimum-age guard cannot be bypassed in production builds (dev_integration.go is test-only). Consider adding rate limiting or audit logging beyond the current info logs. Confirm the DB layer's DeleteForwardingEvents correctly handles context cancellation and large batch sizes.

Security signals we found

01

New destructive RPC added with offchain:write macaroon permission

02

Pre-epoch cutoff guard prevents uint64 UnixNano wrap-around that could delete entire forwarding bucket

03

Minimum age guard (default 1h) limits accidental or malicious deletion of recent events

04

Context is threaded to DB layer so cancellation can abort between batches

05

Hardcoded batch size (10000) noted as temporary; default 0 fallback exists in DB layer

06

Duration parsing supports custom units (d, w, M, y) via parseDuration helper

07

Dev/test config flag can reduce or disable the minimum-age guard

Risk score

Why this scored 41/100

Our methodology →
Potential impact 8/30
Exploitability 7/25
Stealth signal 6/15
Affected reach 9/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.