From 836069516148132c0e4d571489b8b18f044292e4 Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Sun, 5 Mar 2023 13:25:22 +1030 Subject: [PATCH] BOLT #12: remove definitions around "raw invoices". The specification wasn't fully fleshed out for these, so leave them undefined. We can always re-add them in future. Signed-off-by: Rusty Russell --- 12-offer-encoding.md | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/12-offer-encoding.md b/12-offer-encoding.md index 2a3ab3b40..638f48bf7 100644 --- a/12-offer-encoding.md +++ b/12-offer-encoding.md @@ -518,11 +518,8 @@ informative for the payer to know how the sender claims Invoices are a payment request, and when the payment is made, it can be combined with the invoice to form a cryptographic receipt. -The human-readable prefix for invoices is `lni`. The recipient can send it in -response to an `invoice_request` using the `onion_message` `invoice` field -(in which case, it duplicates the fields including the compulsory -`invreq_payer_id`), or can be produced spontanously (in which case, it has -more limited fields, and in particular has no `invreq_payer_id`). +The recipient sends an `invoice` in response to an `invoice_request` using +the `onion_message` `invoice` field. 1. `tlv_stream`: `invoice` 2. types: @@ -716,12 +713,7 @@ A reader of an invoice: - otherwise (invoice_request without an offer): - MAY reject the invoice if it cannot confirm that `invoice_node_id` is correct, out-of-band. - otherwise: (a invoice presented without being requested, eg. scanned by user): - - if `invreq_chain` is not present: - - MUST reject the invoice if bitcoin is not a supported chain. - - otherwise: - - MUST reject the invoice if `invreq_chain` is not a supported chain. - - MUST reject the invoice if `invreq_payer_id` is present. - - MUST reject the invoice if `offer_description` is not present. + - MAY choose to accept or reject the invoice. - MUST reject the invoice if `signature` is not a valid signature using `invoice_node_id` as described in [Signature Calculation](#signature-calculation). - SHOULD prefer to use earlier `invoice_paths` over later ones if it has no other reason for preference. - if `invoice_features` contains the MPP/compulsory bit: @@ -774,6 +766,10 @@ request), the payer needs to ensure that the invoice is from the intended payment recipient. This is the basis for the suggestion to confirm the invoice_node_id for this case. +Raw invoices (not based on an invoice_request) are generally not +supported, though an implementation is allowed to support them, and we +may define the behavior in future. + # Invoice Errors Informative errors can be returned in an onion message `invoice_error`