Good morning CJP, Rusty, and list, > > But why do we need consensus at all? There are two versions of each > > > > commitment transaction: one to be used for unilateral close by one peer > > > > (A), and one to be used by the other (B). Peer A has an interest in > > > > "commit transaction A", so I'd consider it fair to let peer A pay the > > > > transaction fee for that commit tx (subtracted from its part of the > > > > channel funds), and also to let peer A determine the amount of that > > > > fee. If A wants a different fee for whatever reason, it should simply > > > > be able to ask B for a signature on an updated "commit transaction A". > > > > B shouldn't care about that fee, as long as its own funds, HTLCs etc. > > > > are OK.
I was thinking this myself. > We can make them independent (with some twists for the initial case > > where A holds all the funds and must of necessity pay for B's fee too), Perhaps the twisting could be made relatively minimal: at initial funding, assuming `push_msat=0`, then B does not in fact require a commitment transaction: it could just completely forget the channel ever existed, as it has no stake in the channel. And in the case `push_msat!=0`, then B *does* have funds in the channel with which to pay the onchain fee. > Even fixing this is insufficient: neither side may end up being happy > > with the fees when it comes to use the commitment tx. Yes, this is indeed an issue... > > Note that Eltoo works around this by always being a single input/output > > pair with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY (and relying on > > SIGHASH_NOINPUT) so you can attach fees later without this bloat issue. > This works for Decker-Russell-Osuntokun trigger and update transactions, but not for settlement transactions. But then settlement transactions do not have their outputs encumbered with a CSV (it is the settlement transaction itself which is so encumbered), hence allowing direct CPFP. The same technique cannot be used in Poon-Dryja even with `SIGHASH_NOINPUT`, since commitment transactions often have multiple outputs. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
