Make lockBuffer dynamic + additional lockDelta for taker+maker

[kilrau]

Off-shoot of #1157

IMHO, The lockBuffer should be dynamically computed based on the lockDuration of the second leg. Assuming that the average block time on the second leg increases 100% while at the same time the first leg decrease by 50% is very drastic. I agree that there should be a lockBufferFactor (>1) that we should use.

TBD:

• what are reasonable values for this dynamic lockBuffer? Lower bound, %. Upper bound needed?
• do we still need an additional, configurable cltvDelta for taker and maker?

[kilrau]

what are reasonable values for this dynamic lockBuffer? Lower bound, %. Upper bound needed?

Idea: calcuation based on https://en.wikipedia.org/wiki/Poisson_distribution with 99.99% probability that 1st leg is longer than 2nd leg.

do we still need an additional, configurable cltvDelta for taker and maker?

Yes. We want an additional configurable cltvDelta for taker and maker on lightning. For Raiden this should be 0 (or 50?).

[sangaman]

This looks like exactly what we'd need to calculate the buffer to ensure a high probability that the second leg payment does not expire before the first leg payment: https://www.npmjs.com/package/distributions-poisson-quantile . For example that can tell us that the number of bitcoin blocks to ensure a 99.999% chance of taking at least 500 minutes is 83.

The tricky part I need to think about some more is that the second leg payment is not measured in minutes but rather blocks from a different chain, which follow an independent poisson distribution of their own. 576 LTC blocks will not always take 1440 minutes. I believe there I can use the same function as above, for example 99.99% of the time 576 LTC blocks will take 1668 minutes or less, and then I can calculate that 217 BTC blocks will take 1668 minutes or more 99.99% of the time.

We'll bring back the cltvDelta config values for lnd only, and I suppose get rid of lockbuffer from the config entirely. With a cltvDelta value of 40 blocks for BTC and using the example above, we'd use a makerCltvDelta of 40 + 217 = 257 BTC blocks when the second leg has a total time lock of 576 LTC blocks.

[kilrau]

second leg payment is not measured in minutes but rather blocks from a different chain, which follow an independent poisson distribution of their own. 576 LTC blocks will not always take 1440 minutes. I believe there I can use the same function as above, for example 99.99% of the time 576 LTC blocks will take 1668 minutes or less, and then I can calculate that 217 BTC blocks will take 1668 minutes or more 99.99% of the time.

Great! That sound exactly like what needs to be done.

We'll bring back the cltvDelta config values for lnd only, and I suppose get rid of lockbuffer from the config entirely.

Agree too. But let's call it lockDelta to adhere with the new naming convention around lockDuration and lockBuffer.

makerCltvDelta of 40 + 217 = 257 BTC blocks when the second leg has a total time lock of 576 LTC blocks

Numbers make sense, but I still think our terminology is confusing and we should start becoming strict on that. In general I think calling these 257 BTC blocks makerCltvDelta is wrong. Reasons:

1. we want to move from cltv -> lock
I believe the 40 blocks (set in xud.conf) from your example are the makerCltvDelta and as mentioned above, I propose to call it lockDelta. It is the "delta" the maker wants to add to the lockDuration of the 2nd leg.

2. this is not a "delta" but a lockDuration
The total of 257 BTC blocks are simply the minimal lockDuration the maker requires for the first leg. It has nothing to do with a delta.

Let me know what you think.

[sangaman]

Agree too. But let's call it lockDelta to adhere with the new naming convention around lockDuration and lockBuffer.

The config option is specific to lnd and I was going to say I think it's fine to have an lnd specific term here like cltvDelta. But the lnd config option for this is actually called timelockdelta, so lockdelta should be fine. Basically I'm thinking the naming should be intuitive for people who've configured lnd.

2. this is not a "delta" but a lockDuration
   The total of 257 BTC blocks are simply the minimal lockDuration the maker requires for the first leg. It has nothing to do with a delta.

I do think this is a "delta", it's what we'd set for the finalCltvDelta when making the send payment call. That's how many blocks of cltv delay that must be extended to the final hop of the first leg - the total lock duration of the first leg doesn't matter (and in fact will be unknown to the maker, all they see is the last hop coming to them).