bolt12: add invoice_error message for onion message replies#10958
bolt12: add invoice_error message for onion message replies#10958bitromortac wants to merge 7 commits into
Conversation
Add the truncated uint32 (tu32) TLV type used by invoice_relative_expiry and the dynamic invoice subtypes BlindedPayInfo and FallbackAddress, along with their encode/decode helpers and round-trip tests. These primitives are the building blocks for the BOLT 12 Invoice message struct that follows. Isolating them keeps that codec commit focused on the message shape rather than its component records.
…alidators Inject known feature-bit catalogues into the read-side validators to enable correct must-understand capability checks, and remove write-side feature enforcement entirely. Whether a feature bit is "unknown" is a runtime property of the reading node, not of the wire format or pure codec.
Add the BOLT 12 Invoice message: a struct mirroring the invoice_request fields (types 0-91) plus the invoice-specific fields (types 160-176) and the signature (type 240), together with its pure-TLV Encode/DecodeInvoice codec and the UsableFallbackAddresses accessor that applies the spec's MUST-ignore filter. Additionally, add the NewInvoiceFromRequest constructor to build an Invoice from a corresponding request. This copies all non-signature fields from the request (including unknown signed-range TLVs via the decodedTLVs sidecar) and mirrors invreq_amount into invoice_amount.
Implement the structural validators for the BOLT 12 invoice, adding ValidateInvoiceWrite, ValidateInvoiceRead, ValidateInvoiceExpiry, and ValidateInvoiceAgainstRequest. The validators implement the spec writer and reader requirements in the order the spec lists them. The reader confirms the signature TLV is present but defers actual Schnorr verification until the merkle and signing primitives land, mirroring the ValidateInvoiceRequestRead precedent.
Add release notes for the BOLT 12 invoice codec.
InvoiceError is the negative-reply counterpart to an invoice, sent over onion messages at namespace type 68 when the receiver rejects an invoice request or the sender rejects a returned invoice. All three fields are odd (informational): erroneous_field (TLV 1, the offending TLV type), suggested_value (TLV 3, a valid replacement), and error (TLV 5, a UTF-8 explanation). Unlike Offer/InvoiceRequest/Invoice this type has no bech32 form and no Merkle signature — it travels only inside onion message payloads.
🟠 PR Severity: HIGH
🟡 Medium (5 files, bumped to HIGH)
🟢 Low (1 file)
Excluded from counting (test files)
AnalysisAll substantive changes are confined to the However, excluding test files and the release-notes doc, the non-test diff totals 1,699 lines across 5 files (440 + 109 + 361 + 17 + 761), well past the 500-line bump threshold. This triggers a one-level severity bump from MEDIUM → HIGH. Note that To override, add a |
|
I guess this is ready for review, right? |
Yes, would be great 🙏 |
Based on #10941, part of #10736.
Adds the BOLT 12
invoice_errormessage tobolt12.