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 network. 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. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
