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

multi: update models.ChannelAuthProof with v2 field

Public commit record

What the developer wrote

Authored by Elle Mouton

78/100 · Adequate
multi: update models.ChannelAuthProof with v2 field

Also update it to more closely match the persisted version which has the
v1 and v2 only fields as optional.

Refactor ChannelAuthProof to support both v1 and v2 channel
announcements:

- Add Version field to distinguish v1 from v2 proofs
- Wrap v1-specific fields (NodeSig1/2, BitcoinSig1/2) in fn.Option
since v2 doesn't use them
- Add optional Signature field for v2's single schnorr signature
- Add constructor functions NewV1ChannelAuthProof and
NewV2ChannelAuthProof to enforce correct initialization
- Add getter methods (NodeSig1(), BitcoinSig1(), etc.) that safely
unwrap options, returning empty slices when not present

The IsEmpty() check is updated to handle both versions correctly.
Both stores validate v1-only for now.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit refactors how Lightning Network channel authentication proofs are represented in the lnd codebase. It adds support for a future v2 channel announcement format (using a single Schnorr signature) while keeping v1 (four ECDSA signatures) as the only currently supported version. The change is structural and preparatory; it does not appear to fix an active security bug, nor does it introduce obvious new vulnerabilities. Both database stores explicitly reject v2 proofs for now.

Recommended action

Treat as a routine refactor/feature-prep commit. Reviewers should verify that the new getter methods and option wrappers do not introduce nil-slice or empty-slice edge cases in signature validation paths, and that the explicit v1-only guards in both stores are consistently applied. No immediate security response is indicated.

Security signals we found

01

Refactoring of security-critical data structure (channel authentication proof)

02

Explicit rejection of unsupported v2 proofs in both database stores

03

Use of option types to prevent accidental use of absent v1/v2 fields

04

No validation logic changes for v1 signatures observed

05

No mention of CVE, security bug, or vulnerability in commit message

Risk score

Why this scored 32/100

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