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

channeldb: tombstone closed channels without bulk delete

Public commit record

What the developer wrote

Authored by ziggie

83/100 · Strong
channeldb: tombstone closed channels without bulk delete

Wire the tombstone close path on backends that opted in via
OptionTombstoneClosedChannels:

- ChannelStateDB.CloseChannel branches on tombstoneClosedChannels.
The default path remains closeChannelSync; closeChannelTombstone
runs on tombstone-enabled backends.
- closeChannelTombstone leaves every byte of the channel's nested
state in place — chanBucket, revocation log, per-channel
forwarding-package bucket, commitment heads — and relies on the
outpointBucket flip from outpointOpen to outpointClosed (already
performed by the shared updateClosedOutpointIndex helper) as the
authoritative closed-channel marker. The historical-channel and
close-summary archival use the same archiveClosedChannel helper as
the synchronous path so closed-channel and historical readers see
uniform records regardless of backend.
- locateOpenChannel rejects already-closed chanKeys (outpointClosed
in the index) with ErrChannelNotFound so a redundant CloseChannel
is a no-op rather than a re-archive.

Open-channel-bucket readers still surface tombstoned channels — that
audit lands in the next commit. The tests added here only assert the
writer's on-disk artefacts and the redundant-close guard.

Tests:
- TestCloseChannelTombstoneWritePath: outpoint flipped, historical
record, close summary, revlog/fwd-pkgs preserved.
- TestCloseChannelTombstoneRedundantClose: second CloseChannel
returns ErrChannelNotFound.
- TestCloseChannelSync: regression test for the synchronous path —
chanBucket and fwd-pkgs gone, outpoint flipped.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit changes how LND stores closed Lightning channels on certain database backends. Instead of deleting all the old channel data immediately when a channel closes, it now leaves the data in place and just flips a marker saying 'this channel is closed.' This is a performance optimization for SQL-based backends, not a fix for an active security bug. The main risk is that leftover channel data might be read by code that expects only open channels, but the commit adds a guard so repeated close attempts are rejected and the historical/closed-channel records are still written correctly.

Recommended action

Treat as a design/robustness change rather than an urgent security patch. Review the follow-up commit that updates open-channel-bucket readers to respect tombstoned channels, since leaving stale channel buckets readable could confuse callers. Ensure migration tooling for native SQL channel-state cleanup properly reclaims the retained disk space. Run the new tests and any integration tests around channel closure and historical-channel queries.

Security signals we found

01

New database close path leaves sensitive per-channel state on disk instead of deleting it

02

Relies on a single index flag (outpointClosed) as the authoritative 'channel is closed' marker

03

Adds redundant-close guard (ErrChannelNotFound) to prevent duplicate archive writes

04

Commit message acknowledges open-channel readers may still see tombstoned channels in a follow-up commit

05

No input validation, cryptographic, or network changes

Risk score

Why this scored 28/100

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