Skip to content

offersrpc: store the paid BOLT 12 invoice re-encoded, and none above 32 KB - #11

Open
Kilombino wants to merge 1 commit into
paulscode:blake2bfrom
Kilombino:b12-canonical
Open

Kilombino wants to merge 1 commit into
paulscode:blake2bfrom
Kilombino:b12-canonical

Conversation

@Kilombino

Copy link
Copy Markdown

Follow-up to #9, from your review there.

The invoice kept as the payment's request is now re-encoded from its decoded bytes (no + continuations or whitespace; the same TLVs, so the issuer's signature still covers it), and it isn't stored at all above MaxStoredInvoice (32 KB, against ~7 KB for BOLT 11). That keeps listpayments pages bounded when an issuer pads its invoice.

Applied on both paths (fetched from an offer and passed as invoice). Test: TestStoredInvoice in lnrpc/offersrpc (-tags offersrpc).

…2 KB

Follow-up to lightningnetwork#9. The invoice stored as a payment's request was the
caller's string after TrimSpace only; bolt12.Decode accepts '+'
continuations and unknown odd TLVs, so an invoice padded by its issuer
could run to megabytes and every listpayments page holding it would
carry them. It is now re-encoded from its bytes (the same signed TLVs,
so still the issuer's signature over what was paid) and not kept at all
above MaxStoredInvoice (32 KB; BOLT 11 tops out near 7 KB).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant