02+04: add accountability signal to update_add_hltc and onion

Once we have a signal from the recipient, we need a way to propagate
this information throughout the route. Including a signal in the onion
provides an uncorruptable way for the sender to propagate this signal.
If the sender is dishonest, this will eventually be detected by the
final recipient.

In the commits that follow we'll add reputation and resource management
that will allow nodes to use this signal to protect against jamming
attacks.

Author: carlaKC

02-peer-protocol.md

@@ -2233,6 +2233,7 @@ is destined, is described in [BOLT #4](04-onion-routing.md).
     1. type: 0 (`blinded_path`)
     2. data:
         * [`point`:`path_key`]
+    1. type: 1 (`accountable`)
 
 #### Requirements
 
@@ -2271,6 +2272,17 @@ A sending node:
   - MUST increase the value of `id` by 1 for each successive offer.
   - if it is relaying a payment inside a blinded route:
     - MUST set `path_key` (see [Route Blinding](04-onion-routing.md#route-blinding))
+  - if it is the original source of the HTLC:
+    - SHOULD omit `accountable`.
+    - MAY set `accountable` to mimic patterns of HTLCs it has forwarded.
+  - otherwise:
+    - if `accountable` is present in the incoming `update_add_htlc`:
+      - MUST set `accountable`.
+    - otherwise:
+      - if `upgrade_accountability` is present in the onion:
+        - MAY set `accountable`.
+      - otherwise:
+        - MUST NOT set `accountable`.
 
 `id` MUST NOT be reset to 0 after the update is complete (i.e. after `revoke_and_ack` has
 been received). It MUST continue incrementing instead.

04-onion-routing.md

@@ -214,6 +214,7 @@ This is formatted according to the Type-Length-Value format defined in [BOLT #1]
     1. type: 18 (`total_amount_msat`)
     2. data:
         * [`tu64`:`total_msat`]
+    1. type: 19 (`upgrade_accountability`)
 
 `short_channel_id` is the ID of the outgoing channel used to route the
 message; the receiving peer should operate the other end of this channel.
@@ -240,6 +241,9 @@ 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.
 
+`upgrade_accountability` is a marker field that indicates that the 
+forwarding node may set `accountable` in its `update_add_htlc`.
+
 ### Requirements
 
 The creator of `encrypted_recipient_data` (usually, the recipient of payment):
@@ -288,6 +292,10 @@ The writer of the TLV `payload`:
       - if the recipient provided `payment_metadata`:
         - MUST include `payment_metadata` with every HTLC
         - MUST not apply any limits to the size of `payment_metadata` except the limits implied by the fixed onion size
+  - if the recipient provided an invoice with an `accountable` field set:
+    - MUST include `upgrade_accountability` for every node in the route.
+  - otherwise:
+    - MUST NOT include `upgrade_accountability`.
 
 The reader:
 
@@ -339,6 +347,10 @@ The reader:
       - incoming `amount_msat` < `amt_to_forward`.
       - incoming `cltv_expiry` < `outgoing_cltv_value`.
       - incoming `cltv_expiry` < `current_block_height` + `min_final_cltv_expiry_delta`.
+      - `accountable` is set in the incoming `update_add_htlc` but `accountable` was not set in the invoice. 
+  - Otherwise:
+    - MUST return an error if:
+      - `accountable` is set in the incoming `update_add_htlc` but `upgrade_accountability` was not set in the payload.
 
 Additional requirements are specified [here](#basic-multi-part-payments) for
 multi-part payments, and [here](#route-blinding) for blinded payments.
@@ -436,6 +448,11 @@ otherwise meets the amount criterion (eg. some other failure, or
 invoice timeout), however if it were to fulfill only some of them,
 intermediary nodes could simply claim the remaining ones.
 
+`accountable` may only be set in `update_add_htlc` if the receiving 
+node provided an `accountable` signal in its invoice. If the 
+`update_add_htlc` signal is not consistent, a node along the route
+has corrupted this value.
+
 ## Route Blinding
 
 1. subtype: `blinded_path`