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

Rusty Russell rusty at rustcorp.com.au
Mon May 14 03:51:13 UTC 2018


CJP <cjp at ultimatestunts.nl> writes:
> Hi,
>
> Maybe this is a stupid question, and it is late so maybe I'm
> overlooking something, but I don't want to lose a potentially good
> idea, so here it goes:
>
> Right now, BOLT#3 imposes a certain algorithm for fee estimation. This
> algorithm is likely to be sub-optimal: fee estimation is a difficult
> subject, and may involve subjective situation-specific considerations
> of participants. I guess it's only there to achieve some kind of
> consensus between the peers.
>
> 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.

It was an attempt at simplficiation: since A always pays the fee, it
always sets the level.  This means, of course, that B needs to approve
it, particularly since HTLCs pay their own fees (oops!), so actually B
does care about fee levels!

And that got us into this mess.

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),
but the asynchronous nature of updates means it's actually quite a
dance.  I was bracing myself to write propose that in the spec but:

Even fixing this is insufficient: neither side may end up being happy
with the fees when it comes to use the commitment tx.  Thus Laolu
proposal of always having an "OP_TRUE" output and minimal fees, to
basically require you to use CPFP to push the tx.  That costs some
onchain bloat for unilateral closes, but greatly simplfied the fee
problems.

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.

Cheers,
Rusty.


More information about the Lightning-dev mailing list