From rusty at rustcorp.com.au  Mon Jan 15 23:55:09 2018
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Tue, 16 Jan 2018 10:25:09 +1030
Subject: [Lightning-dev] Fee disentanglement for 1.1 spec?
Message-ID: <87shb6iso2.fsf@rustcorp.com.au>

Hi all,

        Wanted to post some thinking on this for everyone to mull over,
though I know we're all busy.

Your consideration and feedback gratefully accepted!

Problem #1
==========
For simplicity, one side (funder) sets fees, but other side
needs to check they're sufficient, and not insanely high (as *they* end
up paying for HTLC txs).  If they disagree, they close channel; this
happens a fair bit on testnet, for example, and will be worse with
different backends (eg. different bitcoind versions, or btcd, etc).

Solution
--------
Have both sides set fees independently.  I specify what fees my
commitment tx and HTLC txs will have, you do the same.  This works in
well with dual-funder proposals.

Implementation:
--------------
c-lightning did something similar pre-spec.  The way it works is both
sides set an initial fee in `open_channel`: this is the only point at
which the counterparty checks it's reasonable.

You send an `update_fee` message like now, but it has no effect on the
other side: it's applied to *you* when they 'revoke_and_ack', like any
other change.

You disallow any `update_fee` which the other side could not afford with
(1) all their current HTLCs, AND (2) the `max_accepted_htlcs` from you.
That covers the race where one side sets fees and the other adds a heap
of HTLCs and the two cross over.

Also disallow any new HTLCs you can't pay fees for (given same
worst-case calculation as above), and if the one side can't afford fees,
pull from its reserve and other side as necessary (this can only happen
during initial phase, and is the same logic as now).


Problem #2
==========
Predicting the future is hard.  Today's sufficient fee may be a gross
overpayment or insufficient tomorrow.

Solution
--------
Allow multiple simultaneous fee levels.

Implementation:
---------------
This means multiple signatures in each `commitment_signed` message,
which is more work and more storage.  But since our nSequence is <
0xFFFFFFFE anyway, all transactions are RBF-ready except
closing_transaction.  We might want to change that; we already allow
re-negotiation of closing tx by reconnecting anyway.