Good morning Corne,

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On May 15, 2018 9:22 PM, Corné Plooy <> 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:

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

Lightning-dev mailing list

Reply via email to