Discussion: some confusion re blinded path `max_cltv`

[ellemouton]

Discussion: some confusion re blinded path `max_cltv`

[t-bast]

I agree this is currently a bit unclear, because there is currently no way in the spec to communicate a blinded route to a potential payer: that is introduced by the Bolt 12 PR, which is why I previously said that it was the responsibility of that PR (or any other PR that uses blinded paths) to detail how max_cltv should be computed. But maybe it's clearer to do it right now, directly in Bolt 4, and let protocols that use blinded paths simply refer to this default construction. If you feel like giving this a shot, I'll gladly review that PR!

But this then violates Alice's initial chosen max_cltv value of 1200.

You are completely correct, and that's a mistake in the example! And when implementing it in eclair, we actually got it right. The mistake is that in the encrypted_data for herself, Alice takes into account the min_final_cltv_expiry and sets max_cltv_expiry to 1212. Everything else remains the same, which works correctly:

• Alice wants the path to expire at block 1200
• She allocates 12 blocks for the min_final_cltv_expiry and 144 blocks for each hop's cltv_expiry_delta, resulting in a final_expiry_delta for the whole path of 300
• The encrypted payload contain:
  • Alice: 1212
  • Bob: 1356
  • Carol: 1500
• Alice communicates to payers that the path's cltv_expiry_delta is 300 and that the path expires at block 1200 (which currently isn't explicitly communicated in Bolt 12, but rather uses the invoice expiry as a proxy for the path expiry - which in practice is fine)
• Erin uses a final CLTV of 1200:
  • Carol receives 1500
  • Carol forwards 1356 to Bob
  • Bob forwards 1212 to Alice
  • And everything should be fine!

This needs to be fixed in proposal doc, probably in the same PR that details how this should be computed!

[ellemouton]

I also think that perhaps some clarification is needed in BOLT 4 to make the answer to the above more clear as currently it is explicit about how the total_fee_base_msat and total_fee_proportional_millionths is calculated but not explicit about the total CLTV (if the CLTV should in fact include the min_final_cltv_delta as is done in the proposal doc, then we should add that to bolt 4.

One other place I think could use some clarity is around if we still expect the sender to add the extra blocks for the "shadow route" or if we can now just leave that up to the receiver since they now have the ability to easily create shadow hops. This was mentioned in this thread in the offers proposal but I think this suggestion should possibly be added to the current spec as it stands today.

Once there is some clarity here, im happy to open a PR 😊