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

Reject offers with some fields present but empty (#3175)

Public commit record

What the developer wrote

Authored by Thomas HUET

81/100 · Strong
Reject offers with some fields present but empty (#3175)

Offers or invoices where the fields `offer_chains`, `offer_paths`, `invoice_paths`, `invoice_blindedpay` are present but empty are considered invalid.
While the spec does not necessarily rejects them explicitly, they can't be paid.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit tightens validation of Bitcoin Lightning 'Bolt 12' offers and invoices. Previously, an offer or invoice could include certain list fields (such as payment paths or supported chains) that were technically present but contained zero entries. The code now rejects these empty-but-present fields during parsing. The change prevents malformed or unpayable offers/invoices from being accepted, which could otherwise confuse wallets, break routing, or be used to probe implementations.

Recommended action

Treat this as a defensive hardening patch. Reviewers should verify that the new `nonEmptyList` codec does not break legitimate offers/invoices that omit these fields entirely, and that downstream consumers no longer assume an empty list is valid. Consider whether other list TLVs in Bolt 12 (or related protocols) need the same treatment.

Security signals we found

01

Input validation hardening for TLV parsing

02

Rejection of malformed Bolt 12 offers/invoices that cannot be paid

03

Prevention of empty-but-present routing/path fields that could cause downstream logic errors

04

Speculative risk of parsing ambiguity between absent and empty list fields

Risk score

Why this scored 52/100

Our methodology →
Potential impact 12/30
Exploitability 10/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.