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

graph/db: rework ChannelUpdateInfo to use lnwire.Timestamp

Public commit record

What the developer wrote

Authored by Elle Mouton

73/100 · Adequate
graph/db: rework ChannelUpdateInfo to use lnwire.Timestamp

Replace the separate Node1UpdateTimestamp/Node2UpdateTimestamp (time.Time)
and Node1BlockHeight/Node2BlockHeight (uint32) fields in ChannelUpdateInfo
with a unified Node1Freshness/Node2Freshness pair typed as lnwire.Timestamp.

The lnwire.Timestamp interface (added in the previous commit) is either a
UnixTimestamp (v1) or BlockHeightTimestamp (v2), making it structurally
impossible to pass block-height values into a v1 constructor or vice versa.

Two version-specific constructors replace the old single constructor:
- NewV1ChannelUpdateInfo(scid, node1Time, node2Time time.Time)
- NewV2ChannelUpdateInfo(scid, node1BlockHeight, node2BlockHeight uint32)

Add Node1FreshnessTime/Node2FreshnessTime helper methods on ChannelUpdateInfo
to extract the underlying time.Time from a UnixTimestamp, which the discovery
syncer needs for its v1-only isStale/isSkewed and isStillZombieChannel checks.

All call sites in kv_store, sql_store, graph_test, and syncer are updated
accordingly.
✓ 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 code cleanup that changes how LND stores 'freshness' timestamps for Lightning channel gossip updates. It replaces separate time and block-height fields with a single typed field that can hold either a Unix timestamp or a block height depending on the gossip protocol version. There is no indication this fixes an active security bug; it appears to be a structural improvement to prevent mixing up v1 and v2 timestamp types.

Recommended action

No security action required. Treat as normal refactoring/code-quality change. Reviewers may verify that NewV2ChannelUpdateInfo call sites are added in a follow-up commit and that Node1FreshnessTime/Node2FreshnessTime are not accidentally used for v2 channels where block-height semantics differ.

Security signals we found

01

Refactoring only: no boundary checks, authorization, cryptographic, or memory-safety changes

02

Type-system hardening: prevents passing block-height values into v1 timestamp fields and vice versa

03

No new external inputs or parsing logic introduced

04

No change to wire message parsing or serialization

05

No mention of vulnerability, CVE, bug, security fix, or reporter in commit message

Risk score

Why this scored 12/100

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