mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 01:50:03 +01:00
Code Issues Projects Releases Wiki Activity

bolt4+proposals: fix max_cltv_expiry calculation (#1176)

Browse Source 
* 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.
This commit is contained in:
Elle 2024-07-15 22:20:48 +02:00 committed by GitHub
parent 93b7ee031b
commit e29fca5703
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 10 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
04-onion-routing.md
View File

@ -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 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 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 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 - `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. - `htlc_minimum_msat` to the largest minimum HTLC value the nodes will allow.
- If it sets `encrypted_data_tlv.allowed_features`: - If it sets `encrypted_data_tlv.allowed_features`:
- MUST set it to an empty array. - 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_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_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). - MUST create the `encrypted_recipient_data` from the `encrypted_data_tlv` as required in [Route Blinding](#route-blinding).
The writer of the TLV `payload`: The writer of the TLV `payload`:

6
proposals/route-blinding.md
View File

@ -261,7 +261,9 @@ total `cltv_expiry_delta`. This yields the following values:
* `route_cltv_expiry_delta`: 300 * `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 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): transmits the following information to the sender (most likely via an invoice):
* Blinded route: `[N(carol), B(bob), B(alice)]` * 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 data for blinded nodes:
* `encrypted_payload(alice)`: * `encrypted_payload(alice)`:
* `path_id`: `payment_preimage` * `path_id`: `payment_preimage`
* `max_cltv_expiry`: 1200 * `max_cltv_expiry`: 1212
* `encrypted_payload(bob)`: * `encrypted_payload(bob)`:
* `outgoing_channel_id`: `scid_bob_alice` * `outgoing_channel_id`: `scid_bob_alice`
* `fee_base_msat`: 100 * `fee_base_msat`: 100