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

graph/db: version NodeUpdatesInHorizon and ChanUpdatesInHorizon

Public commit record

What the developer wrote

Authored by Elle Mouton

73/100 · Adequate
graph/db: version NodeUpdatesInHorizon and ChanUpdatesInHorizon

Replace the (startTime, endTime time.Time) parameters on
NodeUpdatesInHorizon and ChanUpdatesInHorizon with
(v GossipVersion, r NodeUpdateRange/ChanUpdateRange). The range
types enforce version-correct bounds at the type level: v1 uses unix
timestamps, v2 will use block heights.

The KV store rejects non-v1 versions since it only stores v1 data.
The SQL store dispatches to version-specific helpers
(nodeUpdatesInHorizonV1, chanUpdatesInHorizonV1); the v2
block-height paths return an error for now and will be wired up in
follow-up commits.

VersionedGraph wrappers supply the version from the embedded field,
so callers only pass the range.
✓ Specific, 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 queries recent node and channel gossip updates. It changes the function signatures to accept a gossip version and a structured range object instead of raw start/end timestamps. The v1 time-based behavior is preserved, while v2 block-height support is stubbed out to return errors. There is no direct security fix here; it is preparatory plumbing for a future protocol version.

Recommended action

No immediate action required. Treat as routine refactoring. Monitor follow-up commits that wire up v2 block-height queries to ensure validation and indexing remain consistent.

Security signals we found

01

API versioning adds explicit validation and rejects unsupported gossip versions rather than silently interpreting data under the wrong schema

02

Range validation is centralized in validateForVersion, reducing the chance that v2 block-height queries accidentally run against v1 timestamp indexes

03

No memory-safety, cryptographic, or authorization changes are present in the diff

Risk score

Why this scored 19/100

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