Allow nodes to overshoot final htlc amount and expiry (lightning#1032)

When nodes receive HTLCs, they verify that the contents of those HTLCs
match the intructions that the sender provided in the onion. It is
important to ensure that intermediate nodes and final nodes have similar
requirements, otherwise a malicious intermediate node could easily probe
whether the next node is the final recipient or not.

Unfortunately, the requirements for intermediate nodes were more lenient
than the requirements for final nodes. Intermediate nodes allowed overpaying
and increasing the CLTV expiry, whereas final nodes required a perfect
equality between the HTLC values and the onion values.

This provided a trivial way of probing: when relaying an HTLC, nodes could
relay 1 msat more than what the onion instructed (or increase the outgoing
expiry by 1). If the next node was an intermediate node, they would accept
this HTLC, but if the next node was the recipient, they would reject it.

We update those requirements to fix this probing attack vector.

We also clarify `min_final_cltv_expiry`: this is actually a cltv_expiry_delta,
not an absolute cltv_expiry, so the field name should reflect that.

Recipients require incoming HTLC expiry to comply with that expiry delta.

02-peer-protocol.md

@@ -877,9 +877,9 @@ received.
 
 The critical settings here are the `cltv_expiry_delta` in
 [BOLT #7](07-routing-gossip.md#the-channel_update-message) and the
-related `min_final_cltv_expiry` in [BOLT #11](11-payment-encoding.md#tagged-fields).
+related `min_final_cltv_expiry_delta` in [BOLT #11](11-payment-encoding.md#tagged-fields).
 `cltv_expiry_delta` is the minimum difference in HTLC CLTV timeouts, in
-the forwarding case (B). `min_final_cltv_expiry` is the minimum difference
+the forwarding case (B). `min_final_cltv_expiry_delta` is the minimum difference
 between HTLC CLTV timeout and the current block height, for the
 terminal case (C).
 

04-onion-routing.md

@@ -250,15 +250,16 @@ The reader:
   - if it is not the final node:
     - MUST return an error if:
       - `short_channel_id` is not present,
-       - it cannot forward the HTLC to the peer indicated by the channel `short_channel_id`.
-       - incoming `amount_msat` - `fee` < `amt_to_forward` (where `fee` is the advertised fee as described in [BOLT #7](07-routing-gossip.md#htlc-fees))
-       - `cltv_expiry` - `cltv_expiry_delta` < `outgoing_cltv_value`
+      - it cannot forward the HTLC to the peer indicated by the channel `short_channel_id`.
+      - incoming `amount_msat` - `fee` < `amt_to_forward` (where `fee` is the advertised fee as described in [BOLT #7](07-routing-gossip.md#htlc-fees))
+      - `cltv_expiry` - `cltv_expiry_delta` < `outgoing_cltv_value`
   - if it is the final node:
     - MUST treat `total_msat` as if it were equal to `amt_to_forward` if it
       is not present.
     - MUST return an error if:
-       - incoming `amount_msat` != `amt_to_forward`.
-       - incoming `cltv_expiry` != `cltv_expiry_delta`.
+      - incoming `amount_msat` < `amt_to_forward`.
+      - incoming `cltv_expiry` < `outgoing_cltv_value`.
+      - incoming `cltv_expiry` < `current_block_height` + `min_final_cltv_expiry_delta`.
 
 Additional requirements are specified [below](#basic-multi-part-payments).
 
@@ -405,7 +406,7 @@ the final node with the following values:
 * `payment_secret`: set to the payment secret specified by the recipient (e.g.
   `payment_secret` from a [BOLT #11](11-payment-encoding.md) payment invoice)
 * `outgoing_cltv_value`: set to the final expiry specified by the recipient (e.g.
-  `min_final_cltv_expiry` from a [BOLT #11](11-payment-encoding.md) payment invoice)
+  `min_final_cltv_expiry_delta` from a [BOLT #11](11-payment-encoding.md) payment invoice)
 * `amt_to_forward`: set to the final amount specified by the recipient (e.g. `amount`
   from a [BOLT #11](11-payment-encoding.md) payment invoice)
 

07-routing-gossip.md

@@ -1065,7 +1065,7 @@ channel:
 3. C: 30 blocks
 4. D: 40 blocks
 
-C also uses a `min_final_cltv_expiry` of 9 (the default) when requesting
+C also uses a `min_final_cltv_expiry_delta` of 9 (the default) when requesting
 payments.
 
 Also, each node has a set fee scheme that it uses for each of its
@@ -1089,7 +1089,7 @@ The network will see eight `channel_update` messages:
 
 **B->C.** If B were to send 4,999,999 millisatoshi directly to C, it would
 neither charge itself a fee nor add its own `cltv_expiry_delta`, so it would
-use C's requested `min_final_cltv_expiry` of 9. Presumably it would also add a
+use C's requested `min_final_cltv_expiry_delta` of 9. Presumably it would also add a
 _shadow route_ to give an extra CLTV of 42. Additionally, it could add extra
 CLTV deltas at other hops, as these values represent a minimum, but chooses not
 to do so here, for the sake of simplicity:
@@ -1109,7 +1109,7 @@ per [HTLC Fees](#htlc-fees):
         200 + ( 4999999 * 2000 / 1000000 ) = 10199
 
 Similarly, it would need to add B->C's `channel_update` `cltv_expiry_delta` (20), C's
-requested `min_final_cltv_expiry` (9), and the cost for the _shadow route_ (42).
+requested `min_final_cltv_expiry_delta` (9), and the cost for the _shadow route_ (42).
 Thus, A->B's `update_add_htlc` message would be:
 
    * `amount_msat`: 5010198

11-payment-encoding.md

@@ -145,7 +145,7 @@ Currently defined tagged fields are:
 * `n` (19): `data_length` 53. 33-byte public key of the payee node
 * `h` (23): `data_length` 52. 256-bit description of purpose of payment (SHA256). This is used to commit to an associated description that is over 639 bytes, but the transport mechanism for the description in that case is transport specific and not defined here.
 * `x` (6): `data_length` variable. `expiry` time in seconds (big-endian). Default is 3600 (1 hour) if not specified.
-* `c` (24): `data_length` variable. `min_final_cltv_expiry` to use for the last HTLC in the route. Default is 18 if not specified.
+* `c` (24): `data_length` variable. `min_final_cltv_expiry_delta` to use for the last HTLC in the route. Default is 18 if not specified.
 * `f` (9): `data_length` variable, depending on version. Fallback on-chain address: for Bitcoin, this starts with a 5-bit `version` and contains a witness program or P2PKH or P2SH address.
 * `r` (3): `data_length` variable. One or more entries containing extra routing information for a private route; there may be more than one `r` field
    * `pubkey` (264 bits)
@@ -175,7 +175,7 @@ A writer:
   - MAY include one `x` field.
     - if `x` is included:
       - SHOULD use the minimum `data_length` possible.
-  - MUST include one `c` field (`min_final_cltv_expiry`).
+  - MUST include one `c` field (`min_final_cltv_expiry_delta`).
     - MUST set `c` to the minimum `cltv_expiry` it will accept for the last
     HTLC in the route.
     - SHOULD use the minimum `data_length` possible.
@@ -216,7 +216,7 @@ A reader:
     - MUST use the `n` field to validate the signature instead of performing signature recovery.
   - if there is a valid `s` field:
     - MUST use that as [`payment_secret`](04-onion-routing.md#tlv_payload-payload-format)
-  - if the `c` field (`min_final_cltv_expiry`) is not provided:
+  - if the `c` field (`min_final_cltv_expiry_delta`) is not provided:
     - MUST use an expiry delta of at least 18 when making the payment
   - if an `m` field is provided:
     - MUST use that as [`payment_metadata`](04-onion-routing.md#tlv_payload-payload-format)
@@ -618,9 +618,9 @@ Breakdown:
 * `x`: expiry time
   * `qy`: `data_length` (`q` = 0, `y` = 2; 0 * 32 + 4 == 4)
   * `jw5q`: 604800 seconds (`j` = 18, `w` = 14, `5` = 20, `q` = 0; 18 * 32^3 + 14 * 32^2 + 20 * 32 + 0 == 604800)
-* `c`: `min_final_cltv_expiry`
+* `c`: `min_final_cltv_expiry_delta`
   * `qp`: `data_length` (`q` = 0, `p` = 1; 0 * 32 + 1 == 1)
-  * `2`: min_final_cltv_expiry = 10
+  * `2`: min_final_cltv_expiry_delta = 10
 * `r`: tagged field: route information
   * `zj`: `data_length` (`z` = 2, `j` = 18; 2 * 32 + 18 == 82)
   * `q0gxwkzc8w6323m55m4jyxcjwmy7stt9hwkwe2qxmy8zpsgg7jcuwz87fcqqeuqqqyqqqqlgqqqqn3qq9q`: