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

bolt12: add InvoiceError onion message replies

Public commit record

What the developer wrote

Authored by bitromortac

73/100 · Adequate
bolt12: add InvoiceError onion message replies

InvoiceError is the negative-reply counterpart to an invoice, sent over
onion messages at namespace type 68 when the receiver rejects an invoice
request or the sender rejects a returned invoice. All three fields are
odd (informational): erroneous_field (TLV 1, the offending TLV type),
suggested_value (TLV 3, a valid replacement), and error (TLV 5, a UTF-8
explanation). Unlike Offer/InvoiceRequest/Invoice this type has no
bech32 form and no Merkle signature — it travels only inside onion
message payloads.
✓ 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 adds support in LND for a new Lightning protocol message called InvoiceError. It is used to politely tell another node why their payment invoice or invoice request was rejected, sent privately through an onion-routed message. The change is mostly a feature addition with built-in validation to make sure the error message is well-formed before it is sent.

Recommended action

No immediate security action is required. Reviewers should verify that callers of ErrorMessage() sanitize the returned string before logging or UI display, as the code itself explicitly does not sanitize remote-provided bytes. Future work should address the documented FIXME regarding undefined BOLT 12 reader semantic requirements.

Security signals we found

01

New unsigned onion message type added with no cryptographic signature or bech32 form

02

Writer-side validation prevents empty or non-UTF-8 error strings and disallowed suggested_value without erroneous_field

03

Reader-side BOLT 1 must-understand rule enforced: unknown even TLVs rejected, unknown odd TLVs tolerated

04

Encode() intentionally drops unknown TLVs because the message is unsigned

05

ErrorMessage() returns unsanitized remote peer bytes and documents that callers must scrub before logging/display

Risk score

Why this scored 21/100

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