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

bolt12: validate Offer per BOLT 12 reader/writer requirements

Public commit record

What the developer wrote

Authored by bitromortac

73/100 · Adequate
bolt12: validate Offer per BOLT 12 reader/writer requirements

ValidateOfferRead and ValidateOfferWrite enforce the codec-side portion
of the BOLT 12 offer reader and writer requirements. Reader rules cover
TLV range, even-feature-bit rejection, chain mismatch, dependency rules
between offer_amount/description/currency, missing issuer identity,
zero-hop blinded paths, and offer expiry. Writer rules mirror the same
dependency and identity guards plus a defense-in-depth empty-
offer_chains rejection.

offer_currency is validated against the ISO 4217 registry via
golang.org/x/text/currency (now a direct dependency); offer_issuer_id is
verified to be an on-curve SEC1 compressed point on both read and write
paths. Encode invokes Validate so invalid bytes never reach the wire.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds input validation to BOLT 12 offers in the LND Lightning node. BOLT 12 offers are payment requests that one node can present to another. Before this change, LND could accept or re-encode malformed offers that violated the protocol rules, such as offers with no usable payment path, expired offers, invalid currency codes, or hidden unknown required fields. The new code rejects these on both reading and writing, which helps prevent nodes from acting on bad offers or producing invalid ones.

Recommended action

Review where ValidateOfferRead is invoked in the call graph to ensure all inbound BOLT 12 offers are validated before use; confirm that Decode paths call it. Consider whether the nil issuer public key check in ValidateOfferWrite should also verify the point is on the curve, since the commit message mentions on-curve SEC1 compressed point validation but the diff only shows a nil check.

Security signals we found

01

New validation layer for externally supplied BOLT 12 offer messages

02

Rejects unknown even TLV types and feature bits (must-understand fields)

03

Rejects offers missing usable issuer identity or payment path

04

Rejects expired offers and zero-amount offers

05

Validates chain compatibility and defaults to Bitcoin mainnet

06

Validates UTF-8 and ISO 4217 currency codes

07

Wires validation into Encode so invalid offers are not re-serialized

Risk score

Why this scored 59/100

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