Good morning Christian,

Thank you very much!

> > Hi Christian,
> > 
> > Let me know if I have summarized the paper accurately below:
> > 
> > 1.  SIGHASH_NOINPUT removes all inputs of the transaction copy before
> >     
> >     signing/verifying.
> >     
> It sets them to a known constant, in this case we just blank
> them. Removing could entail more costly serialization depending on the
> implementation. bitcoind serializes into a hash accumulator so it'd not
> make a difference there, but others may do it differently.

Does this then mean that if the transaction has two inputs, we are still 
committing to the fact that there are two inputs?  If so, it is probably 
useable together with SIGHASH_ANYONECANPAY.

In fact, it seems, if we are using this to provide additional fees to update 
transactions, we should also use SIGHASH_ANYONECANPAY on the update UTXO path 
so that we can add new inputs to the transaction that will pay for the fee.

> > Some pros and cons relative to Poon-Dryja (LN-penalty) channels:
> > 
> > -   Requires more transactions in the worst-case: trigger, update,
> >     
> >     settlement. Compare to Poon-Dryja: commitment, claim.
> >     
> >     Decker-Russell-Osuntokun channels can be trigger-settlement but only
> >     
> >     in the degenerate case where the channel was never updated (indeed for
> >     
> >     implementation simplicity we might rather prefer to make an initial
> >     
> >     update transaction at the start, instead of starting with a
> >     
> >     trigger-settlement).
> >     
> Actually the trigger can also be replaced in the cooperative case,
> meaning that the settlement in that case is just a single transaction,
> identical to LN-penalty.

Yes, but the intent of this second list is to contrast it to 
Poon-Dryja/LN-penalty channels, so I skipped over similarities (well there is 
the onchannel reserve vs the onchain fee-paying reserve, but I would argue they 
are congruent and not exactly identical).  One can argue that any viable 
channel-update-mechanism should be cooperatively collapsible to a single 
transaction on top of the funding transaction (because neither side has a good 
chance of contesting what has been agreed on, and collapsing them all to a 
single closing transaction is always an improvement due to having less data hit 
the blockchain), so if you did your job right in eltoo (and it looks to me like 
you all have) then that is already a given.

> It is true that we've split the unilateral
> commitment from LN-penalty into two transactions, but we removed the
> need for a claim transaction, since funds directly go to the recipient
> and we have no our_unilateral/to_us or their_unilateral/to_them delay
> that needs to be sweeped (technically also not necessary, but all
> implementation do that if I'm not mistaken). Even if funds are not
> sweeped, the UTXO state is larger due to the bigger script that our
> simple outputs for the settlement.

Ah, that is another difference I had not noticed, thank you.

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

This may complicate routing decisions, however, in a mixed network where some 
channels are Poon-Dryja and some channels are Decker-Russell-Osuntokun; and if 
we deploy this as a back-compatible extension to the Lightning Network rather 
than a completely new network (and we should) then we will have such a mixed 

A payer routing through such a network finding two routes with identical fees 
and cltv-deltas, but one going through only Poon-Dryja channels and the other 
with one channel going through Decker-Russell-Osuntokun (and the rest still 
Poon-Dryja) would prefer the purely Poon-Dryja one, which does not have any 
additional csv-delta to impose on the route.

Further, once a payer can find no purely Poon-Dryja routes, then it no longer 
matters how many Decker-Russell-Osuntokun channels a route hops, because 
csv-deltas are not additive.  Unfortunately most standard routing I know of 
assume additive costs, meaning we would either have a two-phase routing (first 
we try to find only purely Poon-Dryja routes, then if there are none we accept 
Decker-Russell-Osuntokun channels) or hack around with the routing algo to try 
and make things fit.

Finally, it seems to me that it is very unlikely that we would accept some 
centrally-imposed csv-delta.  Instead this would be negotiated between peers 
during channel setup (probably similarly to the current closing fee 
negotiation), and would vary across the network.  Indeed in such a system, 
Poon-Dryja channels would be gossiped as having a csv-delta=0.  But now the 
routing decision on whether to pass through a channel would depend on whether 
the csv-delta is greater than the current route csv-delta or not.  Hmm.


In any case, it seems to me that we could introduce this as a local feature.

`channel_update` would have to be extended with a `csv_delta` parameter.  When 
gossiping with a peer that does not yet understand `csv_delta` we would only 
give it `channel_update` with `csv_delta=0`.  Or maybe we should have a new 
`channel_update` message entirely, since they need to be signed: use the 
current `channel_update` for Poon-Dryja channels, use the new version for 
Decker-Russell-Osuntokun channels.  This way, nodes that are unaware of this 
new channel type just build routemaps of Poon-Dryja channels, which is 
important as they do not know that they need to give a larger margin for 
Decker-Russell-Osuntokun channels.

If a peer does not support Decker-Russell-Osuntokun channels, then it is simply 
impossible to fund such with them.  If it *does* support 
Decker-Russell-Osuntokun channels, then we have a choice to fund either that or 
Poon-Dryja channels.

Lightning-dev mailing list

Reply via email to