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

server: fix timestamp comparison in setSelfNode

Public commit record

What the developer wrote

Authored by ziggie

68/100 · Adequate
server: fix timestamp comparison in setSelfNode

Fix bug where setSelfNode compared only the seconds component of
timestamps instead of the full timestamp. This caused the node to
attempt persisting an older timestamp than what existed in the
database during restart, resulting in "sql: no rows in result set"
errors.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a bug in the LND Lightning node where it compared only the seconds part of timestamps (e.g., the :30 in 12:00:30) instead of the full Unix timestamp when deciding whether to update its own network announcement. Because of this, a node could try to save an announcement with an older timestamp than what was already in its database, which the database rejected with a 'no rows in result set' error. The fix makes the comparison use the full timestamp, preventing restart failures and ensuring the node can rejoin the network properly.

Recommended action

Apply the patch. The fix is straightforward, well-tested, and prevents a real operational failure where a node cannot restart and re-announce itself to the Lightning network. No additional hardening is required beyond the patch.

Security signals we found

01

Incorrect timestamp comparison using time.Second() instead of time.Unix()

02

Potential for violating BOLT-7 strictly-increasing node announcement timestamp requirement

03

Database persistence failure ('sql: no rows in result set') on node restart

04

Node announcement update logic in setSelfNode

05

New helper function calculateNodeAnnouncementTimestamp with bounds checking

Risk score

Why this scored 34/100

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