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

graph/db: use exclusive end time for horizon queries per BOLT 07

Public commit record

What the developer wrote

Authored by Elle Mouton

83/100 · Strong
graph/db: use exclusive end time for horizon queries per BOLT 07

BOLT 07 specifies that gossip_timestamp_filter range semantics are
"greater or equal to first_timestamp, and less than first_timestamp
plus timestamp_range", i.e. [start, end). Three of the four
implementations (KV ChanUpdatesInHorizon, KV NodeUpdatesInHorizon,
SQL NodeUpdatesInHorizon) were incorrectly using an inclusive end
time (<= instead of <). Only SQL ChanUpdatesInHorizon was correct.

This commit fixes the KV store's fetchNextChanUpdateBatch and
fetchNextNodeBatch to use >= (instead of >) for the end time break
condition, and < (instead of <=) for the hasMore check. It also
fixes the SQL GetNodesByLastUpdateRange query to use < instead of <=
on the end_time bound.

All godocs are updated to reference the BOLT 07 spec language and
explicitly document the [start, end) range semantics. New dedicated
tests (TestNodeUpdatesInHorizonExclusiveEnd and
TestChanUpdatesInHorizonExclusiveEnd) verify that items at exactly
the end time are excluded while items at the start time are included.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes a boundary-condition bug in how LND answers peer queries about which Lightning network nodes and channels have recently updated. The code was including updates that happened exactly at the end of the requested time window, but the Lightning protocol (BOLT 07) says the end time should be excluded. The fix makes three database query paths match the spec and adds tests to prevent regression. It is a protocol-compliance bug, not a direct funds-loss vulnerability, but it could cause a node to send or accept one extra gossip update per query window.

Recommended action

Treat as a low-severity protocol-compliance fix. Merge after review. Operators should upgrade to keep gossip behavior spec-compliant and avoid edge-case inconsistencies with peers, but no urgent mitigation is required.

Security signals we found

01

Protocol compliance fix for BOLT 07 gossip_timestamp_filter range semantics

02

Off-by-one boundary error in time-range queries

03

Inconsistent behavior between KV and SQL storage backends

04

Potential for duplicate or unexpected gossip message inclusion at range boundary

05

No input validation bypass, memory corruption, or cryptographic flaw present

Risk score

Why this scored 40/100

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