11+12: add optional accountable field in invoices

The recipient of a payment is ultimately responsible for the fast
resolution of a payment (though intermediate node can, of course,
slow it down).

We add a signal from the final recipient that the sender can use to
reason about the amount of time it should take to resolve.

Author: carlaKC

11-payment-encoding.md

@@ -158,6 +158,7 @@ Currently defined tagged fields are:
 * `9` (5): `data_length` variable. One or more 5-bit values containing features
   supported or required for receiving this payment.
   See [Feature Bits](#feature-bits).
+* `a` (31): `data_length` 0. A marker field that indicates whether the recipient is willing to be held accountable for the timely resolution of the invoice upon HTLC(s) receipt. 
 
 ### Requirements
 
@@ -203,6 +204,10 @@ A writer:
   - MUST pad field data to a multiple of 5 bits, using 0s.
   - if a writer offers more than one of any field type, it:
     - MUST specify the most-preferred field first, followed by less-preferred fields, in order.
+  - if the invoice will be resolved within 90 seconds of HTLC(s) arrival:
+    - SHOULD include a single `a` field
+  - otherwise:
+    - MUST NOT include an `a` field
 
 A reader:
   - MUST skip over unknown fields, OR an `f` field with unknown `version`, OR  `p`, `h` or
@@ -270,6 +275,11 @@ The `r` field allows limited routing assistance: as specified, it only
 allows minimum information to use private channels, however, it could also
 assist in future partial-knowledge routing.
 
+The `a` field indicates that the recipient is willing to be held 
+accountable for the timely resolution of the invoice. In the absence
+of this field, the reader should assume that there are no guarantees
+from the writer about resolution time.
+
 ### Security Considerations for Payment Descriptions
 
 Payment descriptions are user-defined and provide a potential avenue for

12-offer-encoding.md

@@ -644,6 +644,7 @@ the `onion_message` `invoice` field.
         * [`name_len*byte`:`name`]
         * [`u8`:`domain_len`]
         * [`domain_len*byte`:`domain`]
+    1. type: 93 (`accountable`)
     1. type: 160 (`invoice_paths`)
     2. data:
         * [`...*blinded_path`:`paths`]
@@ -745,6 +746,10 @@ A writer of an invoice:
     - MUST include `invoice_blindedpay` with exactly one `blinded_payinfo` for each `blinded_path` in `paths`, in order.
     - MUST set `features` in each `blinded_payinfo` to match `encrypted_data_tlv`.`allowed_features` (or empty, if no `allowed_features`).
     - SHOULD ignore any payment which does not use one of the paths.
+  - if the invoice will be resolved within 90 seconds of HTLC(s) arrival:
+    - SHOULD set `accountable`.
+  - otherwise:
+    - MUST NOT set `accountable`.
 
 A reader of an invoice:
   - MUST reject the invoice if `invoice_amount` is not present.