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

bolt12: validate InvoiceRequest per BOLT 12 reader/writer requirements

Public commit record

What the developer wrote

Authored by bitromortac

88/100 · Strong
bolt12: validate InvoiceRequest per BOLT 12 reader/writer requirements

ValidateInvoiceRequestRead and ValidateInvoiceRequestWrite enforce the
structural BOLT 12 requirements an invoice request can be checked
against on its own. The reader validates incoming requests. The writer
catches out-of-range types in decoded-then-mutated requests before they
leave the local boundary. Type 240 carries the signature and sits
outside the allowed range by spec design. Both validators skip it
during the range scan.

Two reader MUSTs are deferred. Schnorr signature verification against
the merkle root keyed by invreq_payer_id lands with the Invoice
message, where the merkle and signing primitives are shared. Offer
cross-validation requires an Offer reference the structural validator
does not carry, and lands in the bolt12handler layer where both the
request and the stored Offer are in scope.
✓ 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 commit adds validation checks for BOLT 12 invoice requests in the LND Lightning node. It ensures that invoice requests follow protocol rules when being created (written) and received (read), rejecting malformed or non-compliant requests before they are encoded or processed. The change is defensive: it prevents invalid invoice requests from leaving the node or being accepted from peers, which could otherwise lead to payment confusion, incorrect amounts, or protocol incompatibility. Signature verification and full offer cross-checking are intentionally left for future commits.

Recommended action

Review the deferred signature and offer-matching checks to ensure they land promptly, as the current validators alone do not prevent spoofed or mismatched invoice requests. Confirm that callers of ValidateInvoiceRequestRead verify signatures before acting on the request, as the code comments require.

Security signals we found

01

New input validation functions added for protocol messages

02

Validation now runs before encoding, preventing malformed outbound messages

03

Overflow guard added for amount*quantity calculation

04

Unknown even TLV types are rejected to enforce must-understand semantics

05

Signature verification and offer cross-validation explicitly deferred to later commits

Risk score

Why this scored 49/100

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