From e29fca5703540c41896454fece329c908decf289 Mon Sep 17 00:00:00 2001 From: Elle Date: Mon, 15 Jul 2024 22:20:48 +0200 Subject: [PATCH] bolt4+proposals: fix `max_cltv_expiry` calculation (#1176) * BOLT4: include `min_final_cltv_expiry_delta` in `max_cltv_expiry` calc Include `min_final_cltv_expiry_delta` in the `max_cltv_expiry` calculation. Also add a note that indicates that this field may be set for the final node too. This is useful for the final node as then it does not need to persist the path expiry separately and can rely on just checking the `payment_relay` field when the payment arrives. * BOLT4: include calculation for `total_cltv_delta` of a blinded path Include an explicit formula to use for determining the total CLTV delta of a blinded path so that it is clear that it should include the recipient's `min_final_cltv_expiry_delta`. * proposals: fix `max_cltv_expiry` value for final hop in example More info [here](https://github.com/lightning/bolts/issues/1174#issue-2371364610) outlining why the example needed to be updated. --- 04-onion-routing.md | 9 ++++++--- proposals/route-blinding.md | 6 ++++-- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/04-onion-routing.md b/04-onion-routing.md index 4497e1c..e0893df 100644 --- a/04-onion-routing.md +++ b/04-onion-routing.md @@ -246,15 +246,18 @@ The creator of `encrypted_recipient_data` (usually, the recipient of payment): - MUST create `encrypted_data_tlv` for each node in the blinded route (including itself). - MUST include `encrypted_data_tlv.short_channel_id` and `encrypted_data_tlv.payment_relay` for each non-final node. - MUST NOT include `encrypted_data_tlv.next_node_id`. - - MUST set `encrypted_data_tlv.payment_constraints` for each non-final node: + - MUST set `encrypted_data_tlv.payment_constraints` for each non-final node and MAY set it for the final node: - `max_cltv_expiry` to the largest block height at which the route is allowed to be used, starting - from the final node and adding `encrypted_data_tlv.payment_relay.cltv_expiry_delta` at each hop. + from the final node's chosen `max_cltv_expiry` height at which the route should expire, adding + the final node's `min_final_cltv_expiry_delta` and then adding + `encrypted_data_tlv.payment_relay.cltv_expiry_delta` at each hop. - `htlc_minimum_msat` to the largest minimum HTLC value the nodes will allow. - If it sets `encrypted_data_tlv.allowed_features`: - MUST set it to an empty array. - - MUST compute the total fees and cltv delta of the route as follows and communicate them to the sender: + - MUST compute the total fees and CLTV delta of the route as follows and communicate them to the sender: - `total_fee_base_msat(n+1) = (fee_base_msat(n+1) * 1000000 + total_fee_base_msat(n) * (1000000 + fee_proportional_millionths(n+1)) + 1000000 - 1) / 1000000` - `total_fee_proportional_millionths(n+1) = ((total_fee_proportional_millionths(n) + fee_proportional_millionths(n+1)) * 1000000 + total_fee_proportional_millionths(n) * fee_proportional_millionths(n+1) + 1000000 - 1) / 1000000` + - `total_cltv_delta = cltv_delta(0) + cltv_delta(1) + ... + cltv_delta(n) + min_final_cltv_expiry_delta` - MUST create the `encrypted_recipient_data` from the `encrypted_data_tlv` as required in [Route Blinding](#route-blinding). The writer of the TLV `payload`: diff --git a/proposals/route-blinding.md b/proposals/route-blinding.md index 0874b23..6875ab6 100644 --- a/proposals/route-blinding.md +++ b/proposals/route-blinding.md @@ -261,7 +261,9 @@ total `cltv_expiry_delta`. This yields the following values: * `route_cltv_expiry_delta`: 300 Let's assume the current block height is 1000. Alice wants the route to be used in the next 200 -blocks, so she sets `max_cltv_expiry = 1200` and adds `cltv_expiry_delta` for each hop. Alice then +blocks, meaning that the `max_cltv_expiry` she will communicate to the payer will be 1200. She +also wants a `min_final_cltv_expiry_delta` of 12 though and so in the encrypted payload to herself, +she sets `max_cltv_expiry = 1212` and adds `cltv_expiry_delta` for each hop after that. Alice then transmits the following information to the sender (most likely via an invoice): * Blinded route: `[N(carol), B(bob), B(alice)]` @@ -276,7 +278,7 @@ transmits the following information to the sender (most likely via an invoice): * Encrypted data for blinded nodes: * `encrypted_payload(alice)`: * `path_id`: `payment_preimage` - * `max_cltv_expiry`: 1200 + * `max_cltv_expiry`: 1212 * `encrypted_payload(bob)`: * `outgoing_channel_id`: `scid_bob_alice` * `fee_base_msat`: 100