Blinded Paths: clarify outgoing_cltv_value for final hop #1097
Conversation
When paying a blinded path, we don't have a CLTV delta at each hop available, but rather only a total CLTV delta for the entire blinded path. However, the onion format currently still requires that we specify an `outgoing_cltv_value` for the final hop. As the sender, we don't have a sensible value to put there, as we don't know which part of the total CLTV delta belongs to the recipient. The sender is instructed to use the values that are known to them when setting `outgoing_cltv_value` for the final hop: - The current block height. - Any additional delta added to account for block propagation and improve privacy. This change reflects the behavior of some implementations at the time of writing.
There was a problem hiding this comment.
LGTM 👍
People who implemented blinded paths should definitely take a look at https://gist.github.com/t-bast/b1371d357a2c5f3e8c09514a62db7079 and make sure I didn't miss anything (otherwise there may be a probing issue).
|
|
||
| - For every node inside a blinded route: | ||
| - MUST include the `encrypted_recipient_data` provided by the recipient | ||
| - For the first node in the blinded route: | ||
| - MUST include the `blinding_point` provided by the recipient in `current_blinding_point` | ||
| - If it is the final node: | ||
| - MUST include `amt_to_forward`, `outgoing_cltv_value` and `total_amount_msat`. | ||
| - The value set for `outgoing_cltv_value`: | ||
| - MUST use the current block height as a baseline value. |
There was a problem hiding this comment.
If I understand this correctly, the outgoing_cltv_value is a replacement integrity check on the final onion packet to make sure that nodes along the route haven't laid claim to larger shares of the original CLTV budget than they were alotted.
Looking here it states that the final node:
MUST return an error if incoming
cltv_expiry < current_block_height + min_final_cltv_expiry_delta.
It seems to me that if I read your change as written then the final HTLC can be exactly equal to the current block height. This means that without the random offset (specified as SHOULD), then there is zero "headroom" to resolve the HTLC.
Maybe this edge case is allowable, but it does seem to me that we should EITHER:
- relax the baseline from MUST to SHOULD
- constrict the offset recommendation from SHOULD to MUST
- add a mandatory offset > 0 to the current block height as the baseline
Leaving this as is is also acceptable but it would mean that valid implementations of the spec can run into this weird edge case.
There was a problem hiding this comment.
It seems to me that if I read your change as written then the final HTLC can be exactly equal to the current block height. This means that without the random offset (specified as SHOULD), then there is zero "headroom" to resolve the HTLC.
This is not an issue, for two different reasons:
- The same issue exists with non-blinded payments: this is why implementations currently already add a small random offset to the current block height to avoid this issue
- Even if the sender doesn't add a random offset, the recipient will add one in the blinded path's total
cltv_expiry_delta, to make sure it covers itsmin_final_cltv_expiry_delta(to allow the recipient enough time before fulfilling this HTLC without risk of the downstream node using the HTLC-timeout path)
|
Ack! |
This PR replaces #1066, picking this up as discussed in the spec meeting!
Senders making payments to a blinded route know the total
cltv_deltafor the blinded portion of the route, but not themin_final_cltv_deltafor the final hop. This PR updates the instructions for the sender to set the final hop'soutgoing_cltv_detlatocurrent_height + any random offset added.See gist for additional context.