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

bolt12: add bech32 lno/lnr/lni codec

Public commit record

What the developer wrote

Authored by bitromortac

85/100 · Strong
bolt12: add bech32 lno/lnr/lni codec

The bolt12 package can already encode and decode the TLV layer but has
no way to carry an offer as a human-transportable string, which is the
form the spec specifies for QR codes, URLs and email signatures. BOLT
12's envelope is subtractive relative to BIP-173: there is no BCH
checksum, because the BIP-340 signature over the Merkle root already
secures the payload, and a '+' continuation marker may split the string
across lines. btcutil/bech32's public API always wraps the checksum, so
the alphabet layer is duplicated here rather than reused. Enforce a
whitelist of BOLT 12 prefixes (lno, lnr, lni) on both Encode and Decode.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit adds a new encoder/decoder that turns BOLT 12 Lightning payment data (offers, invoice requests, invoices) into human-readable strings like 'lno1...' and back again. It is a feature addition, not a fix for a known vulnerability. The code includes careful input checks for length, character set, case rules, allowed prefixes, and line-continuation markers, plus extensive tests. There is no indication in the commit that this resolves a security incident or was reported by an outside researcher.

Recommended action

Review as a normal feature addition. No immediate security patch action is indicated. Continue monitoring for later commits that wire this codec into P2P/onion-message paths, where input validation and signature verification will become critical.

Security signals we found

01

New codec validates HRP against whitelist (lno/lnr/lni) on both encode and decode

02

Length limits applied before allocation to avoid unbounded input processing

03

Continuation marker parsing rejects leading, trailing, adjacent, and whitespace-only markers

04

Character set restricted to printable ASCII and valid bech32 alphabet

05

Case normalization enforced (all lower or all upper, no mixed case)

06

No checksum verification because BOLT 12 relies on signature over Merkle root

07

Extensive test coverage including spec vectors and property-based round-trip tests

Risk score

Why this scored 23/100

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