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

bolt12: validate Invoice messages

Public commit record

What the developer wrote

Authored by bitromortac

73/100 · Adequate
bolt12: validate Invoice messages

Implement the structural validators for the BOLT 12 invoice, adding
ValidateInvoiceWrite, ValidateInvoiceRead, ValidateInvoiceExpiry, and
ValidateInvoiceAgainstRequest.

The validators implement the spec writer and reader requirements in the
order the spec lists them. The reader confirms the signature TLV is
present but defers actual Schnorr verification until the merkle and
signing primitives land, mirroring the ValidateInvoiceRequestRead
precedent.
✓ Descriptive subject✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit adds validation checks for BOLT 12 invoices in the LND Lightning node software. It ensures invoices contain required fields (creation time, amount, payment hash, node ID, payment paths), match their originating invoice requests, and aren't expired or malformed before being encoded or accepted. The change is defensive: it rejects invalid invoices rather than letting them propagate, which helps prevent payment failures, confusion, or minor abuse. Signature verification is explicitly left for a future patch, so this is not a complete security fix on its own.

Recommended action

Review the deferred TODO for Schnorr signature verification and identity-path binding to ensure those protections land promptly; otherwise an attacker could still craft structurally valid but unsigned or wrongly-signed invoices. Confirm callers actually invoke ValidateInvoiceRead, ValidateInvoiceExpiry, and ValidateInvoiceAgainstRequest in the receive/payment flow, since the codec library does not call them automatically. Consider whether the zero-amount policy extension is acceptable for all BOLT 12 use cases or needs to be configurable.

Security signals we found

01

New validation gate added to Invoice.Encode() to reject malformed invoices before serialization

02

Reader rejects unknown even invoice TLV types and unknown even feature bits

03

Reader enforces chain compatibility against activeChain

04

Reader requires at least one usable blinded path after filtering on known features

05

Writer and reader both reject zero invoice_amount as a policy extension

06

Expiry validator guards against uint64 overflow when adding created_at + relative_expiry

07

Invoice/request validator performs byte-for-byte field mirroring and amount equality

08

Signature verification is explicitly deferred to a future change (TODO)

Risk score

Why this scored 36/100

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