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

@@ -259,6 +259,7 @@ The reader:
     - MUST return an error if:
       - 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`: