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

graph/db: version channelCache by gossip version

Public commit record

What the developer wrote

Authored by Elle Mouton

68/100 · Adequate
graph/db: version channelCache by gossip version

Add a channelCacheKey struct keyed by {GossipVersion, chanID}, matching
the pattern already used by rejectCache. This prevents v1 and v2
channel data from colliding in the shared cache.

All callers in KVStore (always GossipVersion1) and SQLStore (version
from context) are updated to pass the version parameter.

This will be needed for later on when we update methods that use this
cache to be versioned (like ChannelUpdatesInHorizon).
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit changes how LND caches Lightning channel information in memory so that entries are separated by gossip protocol version (v1 vs v2). Previously, the cache used only the channel ID, which could let data for the same channel under different protocol versions overwrite or collide with each other. The fix is preventive: it makes the cache key include the version, matching a similar fix already done for another cache. There is no direct evidence in the commit of an exploitable bug or security incident, but cache collisions between protocol versions could theoretically lead to stale or mixed routing data being served to peers.

Recommended action

Treat as a defensive hardening change. Review whether any currently deployed code paths can populate the cache with GossipVersion2 data before all consumers are version-aware, and ensure follow-up commits complete versioning for ChanUpdatesInHorizon and related methods. No urgent patch or incident response is indicated by the supplied materials.

Security signals we found

01

Cache key collision between gossip protocol versions is addressed

02

Preventive correctness fix for shared cache shared across v1/v2 channel data

03

No explicit security claim, CVE, or exploit scenario in commit message

04

Pattern mirrors existing rejectCache versioning, suggesting prior similar concern

05

SQLStore ChanUpdatesInHorizon still hardcodes GossipVersion1 in cache lookup, indicating future work remains

Risk score

Why this scored 34/100

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