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

graph/db: add v2 policy fields to database layer

Public commit record

What the developer wrote

Authored by Elle Mouton

68/100 · Adequate
graph/db: add v2 policy fields to database layer

Extend channel policy queries and structs to support v2-specific fields:

- Add BlockHeight field to track the block height for v2 policy updates.
- Add DisableFlags field for v2 channel disable messages.

Both fields are nullable (sql.NullInt64/Int16) to maintain backwards
compatibility with v1 channels. The fields are initialized as null in
updateChanEdgePolicy and threaded through all policy-related queries
(GetChannelBySCIDWithPolicies, ListChannelsByNodeID, UpsertEdgePolicy,
etc.) and the extractChannelPolicies helper.

This commit includes both the hand-written SQL query updates and the
corresponding sqlc-generated Go code.
✓ 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 straightforward database schema plumbing change for the LND Lightning node. It adds two new optional fields—block height and disable flags—to the channel policy records so that a future protocol version (v2) can store extra information. The fields are always written as NULL for now, so the change does not by itself fix or introduce any security issue. It simply prepares the data layer for later feature work.

Recommended action

No immediate security action required. Treat as normal feature-prep refactoring. Review the follow-up commits that actually populate BlockHeight/DisableFlags from v2 channel policy messages to assess whether validation and signature verification are handled correctly there.

Security signals we found

01

Database schema extension only

02

New fields are nullable and initialized to NULL in the write path

03

No input validation, authorization, or cryptographic changes

04

No SQL injection pattern: parameterized query placeholders increased from 15 to 17

Risk score

Why this scored 19/100

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