Clarify final cltv expiry computation in route blinding

[valentinewallace]

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]

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]

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]

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]

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]

@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.