Support repeating an invoice_request in payment onions.

This field may be useful for often-offline recipients who did not receive the
invreq when it was originally sent, due to another node providing a keysend
invoice on their behalf.

04-onion-routing.md

@@ -188,6 +188,9 @@ This is formatted according to the Type-Length-Value format defined in [BOLT #1]
 
 1. `tlv_stream`: `payload`
 2. types:
+    1. type: 1 (`invoice_request`)
+    2. data:
+        * [`...*byte`:`invoice_request_tlv_stream`]
     1. type: 2 (`amt_to_forward`)
     2. data:
         * [`tu64`:`amt_to_forward`]
@@ -242,9 +245,10 @@ The requirements ensure consistency in responding to an unexpected
 `outgoing_cltv_value`, whether it is the final node or not, to avoid
 leaking its position in the route.
 
-`keysend_payment_preimage` is the payment preimage provided by the sender in the
-case that the recipient is often-offline and another node provided a keysend
-BOLT 12 invoice on their behalf.
+In the case that the recipient is often-offline and another node provided a
+keysend BOLT 12 invoice on their behalf:
+* `keysend_payment_preimage` is the payment preimage provided by the sender
+* `invoice_request` is the sender's invoice request corresponding to this HTLC.
 
 ### Requirements
 
@@ -280,6 +284,10 @@ The writer of the TLV `payload`:
         - MUST set `keysend_payment_preimage` to randomly generated unique bytes.
         - MUST set `update_add_htlc.payment_hash` to match the SHA256 hash of
           `keysend_payment_preimage`.
+        - if the `payment_onion_invreq` feature is set in the invoice:
+          - MUST or MAY set `invoice_request` to the BOLT 12 invoice request
+            corresponding to this HTLC, based on whether `payment_onion_invreq`
+            is optional or compulsory
       - otherwise:
         - MUST NOT set `keysend_payment_preimage`.
     - MUST NOT include any other tlv field.

12-offer-encoding.md

@@ -679,10 +679,20 @@ the `onion_message` `invoice` field.
 
 ## Invoice Features
 
-| Bits | Description                      | Name           |
-|------|----------------------------------|----------------|
-| 16   | Multi-part-payment support       | MPP/compulsory |
-| 17   | Multi-part-payment support       | MPP/optional   |
+| Bits | Description                                | Name                            |
+|------|--------------------------------------------|---------------------------------|
+| 0    | Include `invoice_request` in payment onion | payment_onion_invreq/compulsory |
+| 1    | Include `invoice_request` in payment onion | payment_onion_invreq/optional   |
+| 16   | Multi-part-payment support                 | MPP/compulsory                  |
+| 17   | Multi-part-payment support                 | MPP/optional                    |
+
+The `payment_onion_invreq` feature indicates that the payer MUST (0) or MAY (1)
+repeat their invoice request in the `update_add_htlc` payment onion.
+
+Often-offline receivers may not have received the payer's invoice request
+originally if another node replied with a keysend invoice on their behalf.
+Providing it to the receiver separately may be useful for verification purposes
+or to supply some other data relevant to the payment.
 
 The 'MPP support' invoice feature indicates that the payer MUST (16) or
 MAY (17) use multiple part payments to pay the invoice.