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

graph/db: add gossip version parameter to ForEachNodeChannel

Public commit record

What the developer wrote

Authored by Elle Mouton

73/100 · Adequate
graph/db: add gossip version parameter to ForEachNodeChannel

Update ForEachNodeChannel to accept a gossip version parameter,
allowing callers to specify which gossip version's channels should be
iterated. This change mirrors the approach taken in ForEachChannel and
prepares the graph database for supporting multiple gossip versions
while maintaining backward compatibility.

The Store interface is updated to include the version parameter, and
both KVStore and SQLStore implementations are updated accordingly:

- KVStore validates that only GossipVersion1 is requested, returning
ErrVersionNotSupportedForKVDB for other versions.
- SQLStore passes the version through to the underlying node query,
enabling version-specific channel iteration.

The ChannelGraph wrapper is updated to accept and pass through the
version parameter. VersionedGraph gains a ForEachNodeChannel method
that automatically uses its configured gossip version, providing a
clean interface for version-specific operations.

Update all call sites to explicitly pass lnwire.GossipVersion1, except
for the local channel manager in server.go which now uses the v1Graph
directly (matching the pattern used in other parts of the codebase).
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit is a routine internal refactoring of how LND's network graph database iterates over a node's channels. It adds a 'gossip version' parameter to one function so the code can eventually support multiple versions of Lightning channel gossip, but currently only version 1 is used. There is no security fix or vulnerability here.

Recommended action

No security action needed. Treat as normal feature/refactoring commit.

Security signals we found

No strong security signals were identified.

Risk score

Why this scored 14/100

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