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

graph/db: update policy builders to support v2 fields

Public commit record

What the developer wrote

Authored by Elle Mouton

73/100 · Adequate
graph/db: update policy builders to support v2 fields

Update buildChanPolicy and related functions in both KV and SQL stores
to properly construct ChannelEdgePolicy with version-specific fields:

KVStore changes:
- Reject non-v1 policies in updateEdgePolicy and serializeChanEdgePolicy
since KV store only supports v1 gossip protocol.
- Set Version to GossipVersion1 when deserializing policies from KV.

SQLStore changes:
- Add isNode1 parameter to buildChanPolicy functions to properly set
SecondPeer field (v2 uses SecondPeer instead of ChannelFlags direction).
- Extract Version from database and populate version-specific fields:
- For v1: MessageFlags, ChannelFlags, LastUpdate, ExtraOpaqueData
- For v2: DisableFlags, LastBlockHeight, ExtraSignedFields
- Thread isNode1 through buildChanPolicyWithBatchData and
buildCachedChanPolicies call sites.

This enables the SQL store to read and reconstruct both v1 and v2
channel policies from the database with proper field mapping.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit updates how the Lightning Network Daemon (LND) stores and rebuilds channel routing policies in its graph database. It adds support for a newer gossip protocol version (v2) in the SQL backend, while the older KV backend is now explicitly restricted to version 1. The changes are primarily about correct data mapping and preventing unsupported versions from being written to the wrong database backend. There is no direct evidence in the commit of an exploitable security vulnerability, but the change touches consensus-relevant routing data and fixes version-handling gaps that could theoretically cause nodes to propagate or accept malformed policy information.

Recommended action

Treat this as a hardening/bugfix change rather than an active vulnerability. Reviewers should verify that the version branching in updateChanEdgePolicy and buildChanPolicy covers all newly introduced v2 fields, that MaxHTLC handling is correct for both versions, and that the KV rejection path cannot be bypassed by callers. Run the updated graph tests under both KV and SQL backends and consider an integration test that exercises a v2 policy end-to-end through gossip propagation.

Security signals we found

01

Version validation added to KV policy write/serialization paths

02

SQL policy builder now distinguishes v1 and v2 gossip protocol fields

03

Directionality field SecondPeer is now set from explicit isNode1 argument rather than inferred from legacy ChannelFlags

04

Unsupported gossip versions rejected in SQL update path

05

Test coverage expanded for dual-version policy round-trips

Risk score

Why this scored 34/100

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