From d5a9966b6a53f2452fab021dd2fe35027e6dddbd Mon Sep 17 00:00:00 2001 From: t-bast Date: Tue, 11 Oct 2022 10:36:26 +0200 Subject: [PATCH 1/2] Allow nodes to overshoot the final htlc amount and expiry 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. --- 04-onion-routing.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/04-onion-routing.md b/04-onion-routing.md index ab09d77db..d1b6c75b3 100644 --- a/04-onion-routing.md +++ b/04-onion-routing.md @@ -250,15 +250,15 @@ 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`. Additional requirements are specified [below](#basic-multi-part-payments). From 391ed8448d39329f351bc940a411fcc612d4b6d7 Mon Sep 17 00:00:00 2001 From: t-bast Date: Tue, 11 Oct 2022 10:38:19 +0200 Subject: [PATCH 2/2] 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 | 4 ++-- 04-onion-routing.md | 3 ++- 07-routing-gossip.md | 6 +++--- 11-payment-encoding.md | 10 +++++----- 4 files changed, 12 insertions(+), 11 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index e0bb5c4da..8a5751c01 100644 --- a/02-peer-protocol.md +++ b/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). diff --git a/04-onion-routing.md b/04-onion-routing.md index d1b6c75b3..018b4129d 100644 --- a/04-onion-routing.md +++ b/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). @@ -397,7 +398,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) diff --git a/07-routing-gossip.md b/07-routing-gossip.md index 66607a448..227c0e6a7 100644 --- a/07-routing-gossip.md +++ b/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 diff --git a/11-payment-encoding.md b/11-payment-encoding.md index a2ae1b62d..bab7c2b30 100644 --- a/11-payment-encoding.md +++ b/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`: