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

Merge pull request #11191 from bitromortac/2604-bolt12-1h

Public commit record

What the developer wrote

Authored by ziggieXXX

58/100 · Thin
Merge pull request #11191 from bitromortac/2604-bolt12-1h

bolt12: finalize the codec package
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Links an issue, advisory, or supporting reference! No meaningful explanatory body
The short version

What changed, and why it matters

This commit finalizes LND's new BOLT 12 codec package. It is mostly a refactor: public Encode/Decode helpers are renamed to internal encodeBech32/decodeBech32, validation helpers are unexported, and new helpers such as EncodeSigned and OfferHash are added. The most user-visible change is that the bech32 decoder no longer rejects very long strings on its own; it now expects the caller (onion-message envelope, RPC, or CLI) to enforce size limits. The commit also adds a display-only DecodeInvoiceStringUnvalidated entry point and tightens signing so that SignInvoice/SignInvoiceRequest run writer validation before producing a signature. There is no explicit bug fix or security patch in the diff; the changes are defensive API hardening.

Recommended action

Treat this as a routine refactor/finalization commit rather than an urgent security patch. Review call sites that previously relied on Decode rejecting oversized strings to ensure they now enforce their own limits. Verify that new EncodeSigned paths are used wherever serialized BOLT 12 messages leave the node, and that DecodeInvoiceStringUnvalidated is only used for already-validated stored data.

Security signals we found

01

Removed decoder-side length limits on BOLT 12 bech32 strings; caller must bound input

02

Added EncodeSigned entry points that enforce signature presence and verification before serialization leaves the node

03

Signing now runs writer validation before producing a signature

04

Added DecodeInvoiceStringUnvalidated display helper that skips reader gates

05

Tightened invoice reader to reject unknown even TLVs inside the signature range (240-1000)

06

OfferHash added for exact-match offer lookup, including unknown TLVs in offer range

07

strictFeaturesRecord encoder changed to reuse lnwire minimal encoding

Risk score

Why this scored 37/100

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