[Roasbeef]

In this PR, we tighten the BOLT 11 decoder in three places where it was more lenient than the spec, and add the spec's invoice test vectors from lightning/bolts#1357 as a test that runs every one of them.

Running those vectors against zpay32.Decode showed that we accepted five invoices the spec says a reader must reject. Three of them are fixed in the decoder:

• A fixed length field (p, h, s, n) with the wrong data_length was treated as absent rather than failing the invoice. For n this meant we'd silently fall back to public key recovery. We now return ErrInvalidFixedFieldLength.
• A second s field was skipped, which leaves the same first vs last ambiguity for the payment secret that zpay32: reject duplicate payment hash fields #11190 closed for the payment hash. bolts#1357 now requires exactly one p and exactly one s, so we return ErrDuplicatePaymentAddr.
• A high-S signature was accepted even when the invoice had an explicit n field. Only the public key recovery path may accept high-S, so we now return ErrHighSSignature.

The other two are already enforced, just later on purpose. An unknown required feature bit is rejected by pathfinding by default, so that decodepayreq can still show the invoice. The test uses WithErrorOnUnknownFeatureBit to check it at decode time. A missing s field stays legal for Decode, as we create blinded path invoices without a payment address. The router already rejects a payment request that has neither, and the test documents that exception.

Compatibility

All three new rejections only affect invoices lnd never produces: our encoder always writes the fixed lengths, a single s field, and low-S signatures. Stored invoices that we decode for ListInvoices are our own, so they're unaffected. A third party invoice that relied on one of these leniencies will now fail to decode. Under the spec it was never valid.

The vectors live in zpay32/test-vectors/invoice-test.json, mirroring bolt12/test-vectors. They come from the bolts#1357 branch, so we should resync the file once that PR lands, in case it changes further.

[github-actions]

🟡 PR Severity: MEDIUM

gh pr view | 6 files | 350 lines changed

🟡 Medium (2 files)

• zpay32/decode.go - BOLT-11 invoice decoding logic
• zpay32/invoice.go - BOLT-11 invoice data structures/helpers

🟢 Low (4 files)

• docs/release-notes/unreleased/11357.md - release notes
• zpay32/bolt11_vectors_test.go - new test file
• zpay32/invoice_internal_test.go - test-only changes
• zpay32/test-vectors/invoice-test.json - test vector fixture data

Analysis

This PR is confined to the zpay32 package (BOLT-11 invoice encode/decode), which falls under MEDIUM severity. The only non-test code changes are modest (~41 lines across decode.go and invoice.go), well below the thresholds for a severity bump (20 files / 500 lines / multiple critical packages). No critical or high-severity packages (lnwallet, htlcswitch, channeldb, etc.) are touched. A knowledgeable reviewer familiar with the BOLT-11 spec should review the decode/encode logic changes; the accompanying test vectors and release note are routine.

---

_{To override, add a severity-override-{critical,high,medium,low} label.}