diff --git a/04-onion-routing.md b/04-onion-routing.md index 63fbdf34f..352b2b8fd 100644 --- a/04-onion-routing.md +++ b/04-onion-routing.md @@ -1658,6 +1658,9 @@ even, of course!). 1. type: 68 (`invoice_error`) 2. data: * [`tlv_invoice_error`:`inverr`] + 1. type: 72 (`bolt11_invoice`) + 2. data: + * [`...*utf8`:`bolt11`] #### Requirements diff --git a/09-features.md b/09-features.md index 1e68c03c7..80f06a1bb 100644 --- a/09-features.md +++ b/09-features.md @@ -28,12 +28,14 @@ The Context column decodes as follows: * `C-`: presented in the `channel_announcement` message, but always odd (optional). * `C+`: presented in the `channel_announcement` message, but always even (required). * `9`: presented in [BOLT 11](11-payment-encoding.md) invoices. +* `2`: presented in [BOLT 12](12-offer-encoding.md) offers. * `B`: presented in the `allowed_features` field of a blinded path. * `T`: used in the `channel_type` field [when opening channels](02-peer-protocol.md#the-open_channel-message). | Bits | Name | Description | Context | Dependencies | Link | |-------|-----------------------------------|-----------------------------------------------------------|----------|-----------------------------|-----------------------------------------------------------------------| | 0/1 | `option_data_loss_protect` | ASSUMED | | | | +| 2/3 | `option_bolt11_request` | Invoice request for a bolt11 invoice | 2 | | [BOLT #12][bolt12-bolt11-req] | | 4/5 | `option_upfront_shutdown_script` | Commits to a shutdown scriptpubkey when opening channel | IN | | [BOLT #2][bolt02-open] | | 6/7 | `gossip_queries` | Peer has useful gossip to share | | | | | 8/9 | `var_onion_optin` | ASSUMED | | | | @@ -113,4 +115,5 @@ This work is licensed under a [Creative Commons Attribution 4.0 International Li [bolt04-mpp]: 04-onion-routing.md#basic-multi-part-payments [bolt04-route-blinding]: 04-onion-routing.md#route-blinding [bolt04-attributable-errors]: 04-onion-routing.md +[bolt12-bolt11-req]: 12-offer-encoding.md#requrements-for-invoice-requests [ml-sighash-single-harmful]: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-September/002796.html diff --git a/12-offer-encoding.md b/12-offer-encoding.md index f5860cffb..65fbc62ff 100644 --- a/12-offer-encoding.md +++ b/12-offer-encoding.md @@ -452,6 +452,7 @@ while still allowing signature validation. * [`name_len*byte`:`name`] * [`u8`:`domain_len`] * [`domain_len*byte`:`domain`] + 1. type: 92 (`invreq_bolt11`) 1. type: 240 (`signature`) 2. data: * [`bip340sig`:`sig`] @@ -480,6 +481,8 @@ The writer: - MUST set `invreq_quantity` less than or equal to `offer_quantity_max`. - otherwise: - MUST NOT set `invreq_quantity` + - if `offer_features` contains `option_bolt11_request`: + - MAY set `invreq_bolt11` to request a bolt11 invoice rather than a bolt12. - otherwise (not responding to an offer): - MUST set `offer_description` to a complete description of the purpose of the payment. - MUST set (or not set) `offer_absolute_expiry` and `offer_issuer` as it would for an offer. @@ -537,7 +540,14 @@ The reader: - MAY reject the invoice request if `invreq_amount`.`msat` greatly exceeds the *expected amount*. - otherwise (no `offer_amount`): - MUST reject the invoice request if it does not contain `invreq_amount`. - - SHOULD send an invoice in response using the `onionmsg_tlv` `reply_path`. + - if `invreq_bolt11` is present: + - if `offer_features` does not contain `option_bolt11_request`: + - MUST reject the invoice request. + - if `invreq_quantity` is present: + - MUST reject the invoice request. + - SHOULD create a BOLT 11 invoice and place it in the `bolt11_invoice` field of a response `onionmsg_tlv`, sent using the `onionmsg_tlv` `reply_path`. + - otherwise: + - SHOULD create an invoice and place it in the `invoice` field of a response `onionmsg_tlv`, sent using the `onionmsg_tlv` `reply_path`. - otherwise (no `offer_issuer_id` or `offer_paths`, not a response to our offer): - MUST reject the invoice request if any of the following are present: - `offer_chains`, `offer_features` or `offer_quantity_max`. @@ -580,6 +590,8 @@ informative for the payer to know how the sender claims The requirement to use `offer_paths` if present, ensures a node does not reveal it is the source of an offer if it is asked directly. Similarly, the requirement that the correct path is used for the offer ensures that cannot be made to reveal that it is the same node that created some other offer. +The `option_bolt11_request` field allows a backwards-compatible mechanism for simple offers, to simplify transition. + # Invoices Invoices are a payment request, and when the payment is made,