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

graph/db: add v2 fields to ChannelEdgePolicy model

Public commit record

What the developer wrote

Authored by Elle Mouton

73/100 · Adequate
graph/db: add v2 fields to ChannelEdgePolicy model

Extend ChannelEdgePolicy to support v2 channel updates by adding:

- Version field to track gossip protocol version (v1 or v2).
- LastBlockHeight for v2's block-height-based timestamps.
- SecondPeer flag to indicate which peer announced the policy in v2.
- DisableFlags for v2-specific channel disable signaling.
- ExtraSignedFields map for v2 extra signed TLV data.

Add version-aware methods:
- IsNode1() determines if the policy was announced by node_1, handling
both v1 (via ChannelFlags direction bit) and v2 (via SecondPeer).
- IsDisabled() checks disable status using ChannelFlags for v1 and
DisableFlags for v2.
- String() provides version-appropriate string representations.

The new fields use zero values for v1 compatibility (Version defaults
to GossipVersion1, LastBlockHeight to 0, SecondPeer to false). This
lays the groundwork for v2 policy support; a subsequent commit will
handle reading and writing these fields from/to the database.
✓ 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 preparatory code change for the Lightning Network gossip protocol. It extends an internal data structure (ChannelEdgePolicy) to store new fields needed for a future 'v2' channel-update format, while keeping existing 'v1' behavior unchanged. It does not, by itself, fix or introduce a security vulnerability; it is groundwork for a later feature.

Recommended action

No immediate security action required. Treat as normal feature groundwork. When reviewing follow-up commits, verify that v2 field serialization, signature verification, and disable-flag handling are correctly implemented and tested before deployment.

Security signals we found

01

No memory-safety, cryptographic, or authorization changes observed

02

New fields default to zero values / GossipVersion1 for backward compatibility

03

IsDisabled() semantics change for v2: returns true only when both incoming and outgoing disabled bits are set, which could affect routing decisions once v2 is live

04

No input validation added for new v2 fields in this commit

Risk score

Why this scored 19/100

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