Good morning Corne,
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On May 15, 2018 9:22 PM, Corné Plooy <co...@bitonic.nl> wrote: > Hi Christian, ZmnSCPxj , > > > > - The CSV-encumberance on settlement transactions, which are the ones > > > > > > which carry the contracts in the channel, affects all > > > > > > absolute-timelocked contracts transported on the channel. Compare to > > > > > > Poon-Dryja, where commitment transactions themselves are unencumbered > > > > > > by CSV, and we simply insert the revocation to spends of the contracts > > > > > > being transported (i.e. the reason why we have HTLC-success and > > > > > > HTLC-timeout transactions in BOLT spec). > > > > > > True, but as I argued in another mail, this is a fixed offset, that is > > > > > > in the same range as today's CLTV deltas for some nodes. So for the > > > > > > network of today using eltoo is roughly equivalent of adding another > > > hop > > > > > > to our path :-) > > > > > Let me think how this is supposed to work (I can't find that other mail > > you're referring to): I believe it is on bitcoin-dev: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015916.html Christian argues that the CSV delay (S in your treatment) is shared across all nodes in the route, but is not additive unlike the CLTV delay. In a heterogeneous network, the S is the maximum S among nodes along the route. I argue elsewhere (https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001230.html) that even if the above is true, it does not mesh well with current routing algorithms; most current "shortest-path" algorithms do not handle well anything that is not additive-cost, and S is effectively the max S along the route. C-lightning is considering to use a "find all paths" algorithm instead, which would simply filter out during route construction any routes that exceed maximum total delay and maximum forwarding fee. This probably works better with "try another route" technique imposed by Lightning forwarding, and would seamlessly support extensions like the above max S or the older "negative fees" idea better than "shortest-path" algorithms; this is done by the simple technique of not actually needing the shortest path (improving privacy by not using the shortest path (we currently add virtual randomized cost multipliers in routing) is already what we do anyway, which is another reason to switch from a "shortest-path" algorithm). Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
