Clarify final cltv expiry computation in route blinding by valentinewallace · Pull Request #1069 · lightning/bolts

valentinewallace · 2023-04-26T14:37:53Z

Based on #1066, see its PR description.

Here we follow-on that change by clarifying the computation of the final outgoing_cltv_value when paying to a blinded route.

I've been implementing route blinding for LDK, and these comments would have alleviated my confusion on how to get the final expiry, so hopefully it seems helpful to others too.

For context, I got the conversion from invoice expiry to CLTV expiry from this offers discussion: https://github.com/lightning/bolts/pull/798/files#r1053000804

t-bast · 2023-05-03T10:25:04Z

Good point, that's something I also brought up a while ago: Bolt 12 doesn't expose the payment_constraints.max_cltv_expiry for the blinded paths that invoices/offers contain. But that's ok, because it can use the max of each of those values across all blinded paths and convert that into the invoice/offer expiry.

It's a bit messy to have to go from blocks to timestamps, but timestamps are more user-friendly when displayed on a commercial website, so we'll probably have to live with that...

@rustyrussell does that match what you had in mind?

valentinewallace · 2023-05-08T19:38:00Z

Good point, that's something I also brought up a while ago: Bolt 12 doesn't expose the payment_constraints.max_cltv_expiry for the blinded paths that invoices/offers contain. But that's ok, because it can use the max of each of those values across all blinded paths and convert that into the invoice/offer expiry.

Right, thanks! I updated the PR description with your original offers comment thread on this topic.

carlaKC · 2023-06-21T19:14:54Z

It's a bit messy to have to go from blocks to timestamps, but timestamps are more user-friendly when displayed on a commercial website, so we'll probably have to live with that...

In the case where an invoice has an expiry < 5 minutes do we assume the current height is the max_cltv_expiry?

t-bast · 2023-06-22T06:59:48Z

In the case where an invoice has an expiry < 5 minutes do we assume the current height is the max_cltv_expiry?

Good point, we'll probably want to create invoices with a very short expiry when responding to an invoice_request. I would put its expiry 2 or 3 blocks away, to account for block propagation before the payment is made.

t-bast · 2023-08-10T09:02:31Z

@valentinewallace can you rebase the last commit on top of master? We should then just merge this now, this is a clarification inside one of the proposals document so doesn't need more than my ACK.

BOLT 12 invoices do not include a max_cltv_expiry field, so it's good to clarify how senders can compute the final outgoing cltv expiry.

valentinewallace · 2023-04-26T14:37:53Z

Based on #1066, see its PR description.

Here we follow-on that change by clarifying the computation of the final outgoing_cltv_value when paying to a blinded route.

I've been implementing route blinding for LDK, and these comments would have alleviated my confusion on how to get the final expiry, so hopefully it seems helpful to others too.

For context, I got the conversion from invoice expiry to CLTV expiry from this offers discussion: https://github.com/lightning/bolts/pull/798/files#r1053000804

t-bast · 2023-05-03T10:25:04Z

Good point, that's something I also brought up a while ago: Bolt 12 doesn't expose the payment_constraints.max_cltv_expiry for the blinded paths that invoices/offers contain. But that's ok, because it can use the max of each of those values across all blinded paths and convert that into the invoice/offer expiry.

It's a bit messy to have to go from blocks to timestamps, but timestamps are more user-friendly when displayed on a commercial website, so we'll probably have to live with that...

@rustyrussell does that match what you had in mind?

valentinewallace · 2023-05-08T19:38:00Z

Good point, that's something I also brought up a while ago: Bolt 12 doesn't expose the payment_constraints.max_cltv_expiry for the blinded paths that invoices/offers contain. But that's ok, because it can use the max of each of those values across all blinded paths and convert that into the invoice/offer expiry.

Right, thanks! I updated the PR description with your original offers comment thread on this topic.

carlaKC · 2023-06-21T19:14:54Z

It's a bit messy to have to go from blocks to timestamps, but timestamps are more user-friendly when displayed on a commercial website, so we'll probably have to live with that...

In the case where an invoice has an expiry < 5 minutes do we assume the current height is the max_cltv_expiry?

t-bast · 2023-06-22T06:59:48Z

In the case where an invoice has an expiry < 5 minutes do we assume the current height is the max_cltv_expiry?

Good point, we'll probably want to create invoices with a very short expiry when responding to an invoice_request. I would put its expiry 2 or 3 blocks away, to account for block propagation before the payment is made.

t-bast · 2023-08-10T09:02:31Z

@valentinewallace can you rebase the last commit on top of master? We should then just merge this now, this is a clarification inside one of the proposals document so doesn't need more than my ACK.

BOLT 12 invoices do not include a max_cltv_expiry field, so it's good to clarify how senders can compute the final outgoing cltv expiry.

valentinewallace · 2023-04-26T14:37:53Z

Based on #1066, see its PR description.

Here we follow-on that change by clarifying the computation of the final outgoing_cltv_value when paying to a blinded route.

I've been implementing route blinding for LDK, and these comments would have alleviated my confusion on how to get the final expiry, so hopefully it seems helpful to others too.

For context, I got the conversion from invoice expiry to CLTV expiry from this offers discussion: https://github.com/lightning/bolts/pull/798/files#r1053000804

t-bast · 2023-05-03T10:25:04Z

Good point, that's something I also brought up a while ago: Bolt 12 doesn't expose the payment_constraints.max_cltv_expiry for the blinded paths that invoices/offers contain. But that's ok, because it can use the max of each of those values across all blinded paths and convert that into the invoice/offer expiry.

It's a bit messy to have to go from blocks to timestamps, but timestamps are more user-friendly when displayed on a commercial website, so we'll probably have to live with that...

@rustyrussell does that match what you had in mind?

valentinewallace · 2023-05-08T19:38:00Z

Good point, that's something I also brought up a while ago: Bolt 12 doesn't expose the payment_constraints.max_cltv_expiry for the blinded paths that invoices/offers contain. But that's ok, because it can use the max of each of those values across all blinded paths and convert that into the invoice/offer expiry.

Right, thanks! I updated the PR description with your original offers comment thread on this topic.

carlaKC · 2023-06-21T19:14:54Z

It's a bit messy to have to go from blocks to timestamps, but timestamps are more user-friendly when displayed on a commercial website, so we'll probably have to live with that...

In the case where an invoice has an expiry < 5 minutes do we assume the current height is the max_cltv_expiry?

t-bast · 2023-06-22T06:59:48Z

In the case where an invoice has an expiry < 5 minutes do we assume the current height is the max_cltv_expiry?

Good point, we'll probably want to create invoices with a very short expiry when responding to an invoice_request. I would put its expiry 2 or 3 blocks away, to account for block propagation before the payment is made.

t-bast · 2023-08-10T09:02:31Z

@valentinewallace can you rebase the last commit on top of master? We should then just merge this now, this is a clarification inside one of the proposals document so doesn't need more than my ACK.

BOLT 12 invoices do not include a max_cltv_expiry field, so it's good to clarify how senders can compute the final outgoing cltv expiry.

valentinewallace · 2023-04-26T14:37:53Z

Based on #1066, see its PR description.

Here we follow-on that change by clarifying the computation of the final outgoing_cltv_value when paying to a blinded route.

I've been implementing route blinding for LDK, and these comments would have alleviated my confusion on how to get the final expiry, so hopefully it seems helpful to others too.

For context, I got the conversion from invoice expiry to CLTV expiry from this offers discussion: https://github.com/lightning/bolts/pull/798/files#r1053000804

t-bast · 2023-05-03T10:25:04Z

Good point, that's something I also brought up a while ago: Bolt 12 doesn't expose the payment_constraints.max_cltv_expiry for the blinded paths that invoices/offers contain. But that's ok, because it can use the max of each of those values across all blinded paths and convert that into the invoice/offer expiry.

It's a bit messy to have to go from blocks to timestamps, but timestamps are more user-friendly when displayed on a commercial website, so we'll probably have to live with that...

@rustyrussell does that match what you had in mind?

valentinewallace · 2023-05-08T19:38:00Z

Good point, that's something I also brought up a while ago: Bolt 12 doesn't expose the payment_constraints.max_cltv_expiry for the blinded paths that invoices/offers contain. But that's ok, because it can use the max of each of those values across all blinded paths and convert that into the invoice/offer expiry.

Right, thanks! I updated the PR description with your original offers comment thread on this topic.

carlaKC · 2023-06-21T19:14:54Z

It's a bit messy to have to go from blocks to timestamps, but timestamps are more user-friendly when displayed on a commercial website, so we'll probably have to live with that...

In the case where an invoice has an expiry < 5 minutes do we assume the current height is the max_cltv_expiry?

t-bast · 2023-06-22T06:59:48Z

In the case where an invoice has an expiry < 5 minutes do we assume the current height is the max_cltv_expiry?

Good point, we'll probably want to create invoices with a very short expiry when responding to an invoice_request. I would put its expiry 2 or 3 blocks away, to account for block propagation before the payment is made.

t-bast · 2023-08-10T09:02:31Z

@valentinewallace can you rebase the last commit on top of master? We should then just merge this now, this is a clarification inside one of the proposals document so doesn't need more than my ACK.

BOLT 12 invoices do not include a max_cltv_expiry field, so it's good to clarify how senders can compute the final outgoing cltv expiry.

valentinewallace · 2023-04-26T14:37:53Z

Based on #1066, see its PR description.

Here we follow-on that change by clarifying the computation of the final outgoing_cltv_value when paying to a blinded route.

I've been implementing route blinding for LDK, and these comments would have alleviated my confusion on how to get the final expiry, so hopefully it seems helpful to others too.

For context, I got the conversion from invoice expiry to CLTV expiry from this offers discussion: https://github.com/lightning/bolts/pull/798/files#r1053000804

t-bast · 2023-05-03T10:25:04Z

Good point, that's something I also brought up a while ago: Bolt 12 doesn't expose the payment_constraints.max_cltv_expiry for the blinded paths that invoices/offers contain. But that's ok, because it can use the max of each of those values across all blinded paths and convert that into the invoice/offer expiry.

It's a bit messy to have to go from blocks to timestamps, but timestamps are more user-friendly when displayed on a commercial website, so we'll probably have to live with that...

@rustyrussell does that match what you had in mind?

valentinewallace · 2023-05-08T19:38:00Z

Good point, that's something I also brought up a while ago: Bolt 12 doesn't expose the payment_constraints.max_cltv_expiry for the blinded paths that invoices/offers contain. But that's ok, because it can use the max of each of those values across all blinded paths and convert that into the invoice/offer expiry.

Right, thanks! I updated the PR description with your original offers comment thread on this topic.

carlaKC · 2023-06-21T19:14:54Z

It's a bit messy to have to go from blocks to timestamps, but timestamps are more user-friendly when displayed on a commercial website, so we'll probably have to live with that...

In the case where an invoice has an expiry < 5 minutes do we assume the current height is the max_cltv_expiry?

t-bast · 2023-06-22T06:59:48Z

In the case where an invoice has an expiry < 5 minutes do we assume the current height is the max_cltv_expiry?

Good point, we'll probably want to create invoices with a very short expiry when responding to an invoice_request. I would put its expiry 2 or 3 blocks away, to account for block propagation before the payment is made.

t-bast · 2023-08-10T09:02:31Z

@valentinewallace can you rebase the last commit on top of master? We should then just merge this now, this is a clarification inside one of the proposals document so doesn't need more than my ACK.

BOLT 12 invoices do not include a max_cltv_expiry field, so it's good to clarify how senders can compute the final outgoing cltv expiry.

valentinewallace · 2023-04-26T14:37:53Z

Based on #1066, see its PR description.

Here we follow-on that change by clarifying the computation of the final outgoing_cltv_value when paying to a blinded route.

I've been implementing route blinding for LDK, and these comments would have alleviated my confusion on how to get the final expiry, so hopefully it seems helpful to others too.

For context, I got the conversion from invoice expiry to CLTV expiry from this offers discussion: https://github.com/lightning/bolts/pull/798/files#r1053000804

t-bast · 2023-05-03T10:25:04Z

Good point, that's something I also brought up a while ago: Bolt 12 doesn't expose the payment_constraints.max_cltv_expiry for the blinded paths that invoices/offers contain. But that's ok, because it can use the max of each of those values across all blinded paths and convert that into the invoice/offer expiry.

It's a bit messy to have to go from blocks to timestamps, but timestamps are more user-friendly when displayed on a commercial website, so we'll probably have to live with that...

@rustyrussell does that match what you had in mind?

valentinewallace · 2023-05-08T19:38:00Z

Good point, that's something I also brought up a while ago: Bolt 12 doesn't expose the payment_constraints.max_cltv_expiry for the blinded paths that invoices/offers contain. But that's ok, because it can use the max of each of those values across all blinded paths and convert that into the invoice/offer expiry.

Right, thanks! I updated the PR description with your original offers comment thread on this topic.

carlaKC · 2023-06-21T19:14:54Z

It's a bit messy to have to go from blocks to timestamps, but timestamps are more user-friendly when displayed on a commercial website, so we'll probably have to live with that...

In the case where an invoice has an expiry < 5 minutes do we assume the current height is the max_cltv_expiry?

t-bast · 2023-06-22T06:59:48Z

In the case where an invoice has an expiry < 5 minutes do we assume the current height is the max_cltv_expiry?

Good point, we'll probably want to create invoices with a very short expiry when responding to an invoice_request. I would put its expiry 2 or 3 blocks away, to account for block propagation before the payment is made.

t-bast · 2023-08-10T09:02:31Z

@valentinewallace can you rebase the last commit on top of master? We should then just merge this now, this is a clarification inside one of the proposals document so doesn't need more than my ACK.

BOLT 12 invoices do not include a max_cltv_expiry field, so it's good to clarify how senders can compute the final outgoing cltv expiry.

valentinewallace · 2023-04-26T14:37:53Z

Based on #1066, see its PR description.

Here we follow-on that change by clarifying the computation of the final outgoing_cltv_value when paying to a blinded route.

I've been implementing route blinding for LDK, and these comments would have alleviated my confusion on how to get the final expiry, so hopefully it seems helpful to others too.

For context, I got the conversion from invoice expiry to CLTV expiry from this offers discussion: https://github.com/lightning/bolts/pull/798/files#r1053000804

t-bast · 2023-05-03T10:25:04Z

Good point, that's something I also brought up a while ago: Bolt 12 doesn't expose the payment_constraints.max_cltv_expiry for the blinded paths that invoices/offers contain. But that's ok, because it can use the max of each of those values across all blinded paths and convert that into the invoice/offer expiry.

It's a bit messy to have to go from blocks to timestamps, but timestamps are more user-friendly when displayed on a commercial website, so we'll probably have to live with that...

@rustyrussell does that match what you had in mind?

valentinewallace · 2023-05-08T19:38:00Z

Good point, that's something I also brought up a while ago: Bolt 12 doesn't expose the payment_constraints.max_cltv_expiry for the blinded paths that invoices/offers contain. But that's ok, because it can use the max of each of those values across all blinded paths and convert that into the invoice/offer expiry.

Right, thanks! I updated the PR description with your original offers comment thread on this topic.

carlaKC · 2023-06-21T19:14:54Z

It's a bit messy to have to go from blocks to timestamps, but timestamps are more user-friendly when displayed on a commercial website, so we'll probably have to live with that...

In the case where an invoice has an expiry < 5 minutes do we assume the current height is the max_cltv_expiry?

t-bast · 2023-06-22T06:59:48Z

In the case where an invoice has an expiry < 5 minutes do we assume the current height is the max_cltv_expiry?

Good point, we'll probably want to create invoices with a very short expiry when responding to an invoice_request. I would put its expiry 2 or 3 blocks away, to account for block propagation before the payment is made.

t-bast · 2023-08-10T09:02:31Z

@valentinewallace can you rebase the last commit on top of master? We should then just merge this now, this is a clarification inside one of the proposals document so doesn't need more than my ACK.

BOLT 12 invoices do not include a max_cltv_expiry field, so it's good to clarify how senders can compute the final outgoing cltv expiry.

valentinewallace · 2023-04-26T14:37:53Z

Based on #1066, see its PR description.

Here we follow-on that change by clarifying the computation of the final outgoing_cltv_value when paying to a blinded route.

I've been implementing route blinding for LDK, and these comments would have alleviated my confusion on how to get the final expiry, so hopefully it seems helpful to others too.

For context, I got the conversion from invoice expiry to CLTV expiry from this offers discussion: https://github.com/lightning/bolts/pull/798/files#r1053000804

t-bast · 2023-05-03T10:25:04Z

Good point, that's something I also brought up a while ago: Bolt 12 doesn't expose the payment_constraints.max_cltv_expiry for the blinded paths that invoices/offers contain. But that's ok, because it can use the max of each of those values across all blinded paths and convert that into the invoice/offer expiry.

It's a bit messy to have to go from blocks to timestamps, but timestamps are more user-friendly when displayed on a commercial website, so we'll probably have to live with that...

@rustyrussell does that match what you had in mind?

valentinewallace · 2023-05-08T19:38:00Z

Good point, that's something I also brought up a while ago: Bolt 12 doesn't expose the payment_constraints.max_cltv_expiry for the blinded paths that invoices/offers contain. But that's ok, because it can use the max of each of those values across all blinded paths and convert that into the invoice/offer expiry.

Right, thanks! I updated the PR description with your original offers comment thread on this topic.

carlaKC · 2023-06-21T19:14:54Z

It's a bit messy to have to go from blocks to timestamps, but timestamps are more user-friendly when displayed on a commercial website, so we'll probably have to live with that...

In the case where an invoice has an expiry < 5 minutes do we assume the current height is the max_cltv_expiry?

t-bast · 2023-06-22T06:59:48Z

In the case where an invoice has an expiry < 5 minutes do we assume the current height is the max_cltv_expiry?

Good point, we'll probably want to create invoices with a very short expiry when responding to an invoice_request. I would put its expiry 2 or 3 blocks away, to account for block propagation before the payment is made.

t-bast · 2023-08-10T09:02:31Z

@valentinewallace can you rebase the last commit on top of master? We should then just merge this now, this is a clarification inside one of the proposals document so doesn't need more than my ACK.

BOLT 12 invoices do not include a max_cltv_expiry field, so it's good to clarify how senders can compute the final outgoing cltv expiry.

t-bast mentioned this pull request May 5, 2023
Lightning Specification Meeting 2023/05/08 #1076
Closed
28 tasks

t-bast mentioned this pull request May 17, 2023
Lightning Specification Meeting 2023/05/22 #1082
Closed
28 tasks

t-bast mentioned this pull request Jun 2, 2023
Lightning Specification Meeting 2023/06/05 #1085
Closed
29 tasks

t-bast mentioned this pull request Jun 14, 2023
Lightning Specification Meeting 2023/06/19 #1088
Closed
28 tasks

carlaKC mentioned this pull request Jun 21, 2023
routing: Support Pathfinding to Blinded Routes lightningnetwork/lnd#7267
Merged

t-bast mentioned this pull request Jul 12, 2023
Lightning Specification Meeting 2023/07/17 #1094
Closed
30 tasks

t-bast mentioned this pull request Jul 27, 2023
Lightning Specification Meeting 2023/07/31 #1098
Closed
27 tasks

Clarify computation of final outgoing_expiry in route blinding
f271735
BOLT 12 invoices do not include a max_cltv_expiry field, so it's good to clarify how senders can compute the final outgoing cltv expiry.

valentinewallace force-pushed the 2023-04-blinded-final-outgoing-cltv branch from a48cfdc to f271735Compare August 11, 2023 15:16

t-bast approved these changes Aug 11, 2023
View reviewed changes

t-bast merged commit fbd19ef into lightning:masterAug 11, 2023

valentinewallace mentioned this pull request Aug 14, 2023
Route Blinding (Feature 24/25) #765
Merged

valentinewallace mentioned this pull request Dec 15, 2023
Multi-hop BlindedPath creation interface lightningdevkit/rust-lightning#2781
Merged

valentinewallace mentioned this pull request Jul 1, 2024
bolt4+proposals: fix max_cltv_expiry calculation #1176
Merged