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

graph/db: add versioned HasChannelEdge method

Public commit record

What the developer wrote

Authored by Elle Mouton

68/100 · Adequate
graph/db: add versioned HasChannelEdge method

Add a new HasChannelEdge method that takes a gossip version parameter
and returns only existence and zombie status, without timestamp data.
This supports both v1 and v2 gossip protocols.

The original HasChannelEdge method is renamed to HasV1ChannelEdge to
preserve v1-specific functionality for callers that need timestamp
information. All call sites are updated accordingly.

The SQL store implementation now handles both gossip versions, using
timestamps for v1 and block heights for v2 policies, with proper
reject cache support for both versions.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit refactors how LND checks whether a Lightning channel edge exists in its graph database, adding support for both v1 and v2 gossip protocols. It is a code-maintenance and feature-extension change, not a direct security fix. There is no vendor statement or external report linking it to a known vulnerability, and the diff does not show a patch for an exploitable bug. However, because it touches core graph/caching logic, any mistake could affect routing or spam handling, so it warrants normal review rather than urgent response.

Recommended action

Treat as a normal code-review item: verify that the new versioned HasChannelEdge correctly handles cache coherency, zombie checks, and error paths for both gossip versions, and that callers needing timestamps still use HasV1ChannelEdge. No immediate security response is indicated by the available evidence.

Security signals we found

01

Refactor of core graph edge existence check used in routing/gossip validation

02

New version-aware SQL path with cache insertion for both v1 and v2 policies

03

KVStore explicitly rejects non-v1 gossip versions for the new method

04

No explicit security claim, CVE, or advisory in commit message or diff

Risk score

Why this scored 34/100

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