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

channeldb: hide tombstoned channels from open views

Public commit record

What the developer wrote

Authored by ziggie

95/100 · Strong
channeldb: hide tombstoned channels from open views

Wire every reader of openChannelBucket to consult isOutpointClosed
before treating a chanKey as open. Without this commit the previous one
flips the outpoint index but FetchAllChannels and friends still surface
the channel as if it were open — that intermediate state is fine for
tests because OptionTombstoneClosedChannels stays off until the multi:
commit flips it on for sqlite/postgres, but the readers must be wired
before that lands.

Audit covers all six call sites that descend into chanBucket:

- fetchChanBucket / fetchChanBucketRw — direct lookup paths used by
Refresh, MarkBorked, and the rest of OpenChannel's read/write
methods. Single-call sites; the tx.ReadBucket(outpointBucket)
lookup is inlined into the isOutpointClosed call.
- fetchNodeChannels — per-node ForEach iteration; tx threaded
through and the outpoint-bucket lookup is hoisted above the loop
so the closed-channel check is a per-iteration map probe rather
than a tx-level bucket resolve.
- FetchPermAndTempPeers — cross-node ForEach; same hoisting pattern.
The closed peer's protected status is still established by the
historical-channel second pass that runs after the open-channel
pass.
- channelScanner — single-channel-selector iteration site reached by
FetchChannel and FetchChannelByID; outpoint-bucket lookup hoisted
inside chanScan so a single visit pays the bucket-resolve cost
once.

The redundant-close guard added in the previous commit lives in
locateOpenChannel and is unchanged here.

Tests:
- TestCloseChannelTombstoneRemovesFromOpenScans: end-to-end —
FetchAllChannels, FetchOpenChannels, and FetchPermAndTempPeers all
behave as if the closed channel is gone, while the historical pass
still marks the peer as having a closed channel.
- TestClosedChannelHiddenFromFetchChannel: channelScanner path.
- TestClosedChannelHiddenFromDirectMethods: fetchChanBucket /
fetchChanBucketRw via Refresh and MarkBorked.
✓ 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 fixes an internal bookkeeping bug in LND's channel database. A new 'tombstone' close feature keeps closed channel data on disk but marks the channel as closed in a separate index. Before this fix, several database readers still treated those tombstoned channels as if they were open, which could make the node try to use or report already-closed channels as active. The patch wires every reader to check the closed-channel index first. It is a correctness fix rather than a remote exploit, but it prevents state confusion that could affect routing, channel management, or peer protections.

Recommended action

Reviewers should confirm that no additional open-channel readers bypass the outpointBucket check, and that the follow-up commit enabling OptionTombstoneClosedChannels for sqlite/postgres lands together with this change. Operators on bbolt/etcd are unaffected because tombstones remain disabled there. No immediate emergency response is warranted, but the fix should be included in the next release.

Security signals we found

01

State-consistency bug: closed channels could be surfaced as open

02

Tombstone index (outpointBucket) not consulted by multiple readers

03

Potential for stale channel state to influence routing, peer management, or channel operations

04

Fix is preparatory: tombstone feature not yet enabled for sqlite/postgres in this commit

05

No remote attacker-controlled input path visible in the diff

Risk score

Why this scored 59/100

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