[Lightning-dev] Why do we need fee estimation in the protocol?

[ZmnSCPxj]

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