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

bolt12: verify invoice_request and invoice signatures on read

Public commit record

What the developer wrote

Authored by bitromortac

88/100 · Strong
bolt12: verify invoice_request and invoice signatures on read

ValidateInvoiceRequestRead and ValidateInvoiceRead now run
VerifyInvoiceRequest and VerifyInvoice as their final step, so a
decoded message whose BIP-340 signature does not verify against
invreq_payer_id or invoice_node_id is rejected instead of only
checked for presence. This satisfies the reader-side MUSTs of the
BOLT 12 invoice_request and invoice requirements, and the docstrings
now state the contract instead of deferring it to callers.

The invoice_request wiring is pinned by the spec's signed vector; no
signed invoice vector exists, so the invoice side is pinned by
round-trip tests. Reader-validation fixtures now sign with Bob's
key, and the happy-path invoice_request test reuses the shared
validInvoiceRequest fixture.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This change makes LND's BOLT 12 invoice and invoice-request reader actually check that the digital signature is valid, instead of only checking that a signature field exists. Before, an attacker could craft or modify a BOLT 12 message and include any 64-byte placeholder as a 'signature'; the reader would accept it as long as the field was present. Now the reader verifies the signature cryptographically against the claimed sender public key, rejecting forgeries and tampered messages. This is a security-hardening fix that closes a real authentication gap.

Recommended action

Review any callers that previously relied on ValidateInvoiceRequestRead/ValidateInvoiceRead only for structural checks, because these functions now return ErrInvalidSignature for bad signatures. Ensure production signing keys match invoice_node_id/invreq_payer_id. Backport to release branches supporting BOLT 12. No immediate incident response is indicated unless malformed BOLT 12 messages were already accepted in the wild.

Security signals we found

01

Missing cryptographic verification on parsed BOLT 12 messages replaced with BIP-340 Schnorr signature verification

02

Reader accepted any 64-byte placeholder signature before the patch

03

New negative tests verify rejection of wrong-signer and tampered Merkle-root fields

04

Fixes a TODO that explicitly deferred signature verification to callers

05

BOLT 12 spec reader-side MUST for signature correctness now enforced

Risk score

Why this scored 60/100

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