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

lnwire: reject onion message payloads with multiple final hop fields

Public commit record

What the developer wrote

Authored by bitromortac

83/100 · Strong
lnwire: reject onion message payloads with multiple final hop fields

BOLT 4 requires the final node to ignore an onion message whose
onionmsg_tlv contains more than one payload field, where payload fields
are the tlv types reserved for the final hop (type 64 and above). Decode
previously accumulated every such field it found, so a payload bundling
invoice_request, invoice, and invoice_error together was accepted.

Reject the payload when more than one final hop field is present. Every
entry collected in FinalHopTLVs is in the final hop range, so its count
is the number of payload fields. The round-trip test for multiple fields
becomes a rejection test, and the property test now draws at most one
payload field.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This change tightens how LND handles special 'final hop' data in onion-routed Lightning messages. Previously, a message could bundle several final-hop payload types (such as an invoice request, an invoice, and an invoice error) together and still be accepted. The patch now rejects any onion message that contains more than one such final-hop payload, matching the BOLT 4 specification. This prevents protocol confusion where a single message might be interpreted in conflicting ways.

Recommended action

Review whether any deployed code or dependent services relied on accepting multiple final-hop TLVs in a single onion message, since this change turns previously accepted payloads into decode errors. Consider backporting to release branches that support onion messages.

Security signals we found

01

Protocol-conformance fix enforcing BOLT 4 final-hop payload count rule

02

Prevents ambiguous or conflicting final-hop message interpretation

03

Rejects bundled invoice_request/invoice/invoice_error payloads

04

Adds explicit error return for multiple final-hop payload fields

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.