From rusty at rustcorp.com.au  Mon Feb  8 20:17:07 2016
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Tue, 09 Feb 2016 06:47:07 +1030
Subject: [Lightning-dev] Simplified protocol for multiple in-flight updates.
References: <878u34oi9q.fsf@rustcorp.com.au>
Message-ID: <878u2vgdoc.fsf@rustcorp.com.au>

Hi all!

        Eliminating all acknowledgements makes for a much simpler
protocol.

        Each side sends one or more updates
(ADD/SETTLE/TIMEOUT/FAIL/UNADD), followed by a COMMIT (with sig).  Reply
COMPLETE with the old revocation preimage.  Each side tracks two commit
txs: its own and the other side's.  When you COMMIT you're locking in
your updates to my commit, and staging them for your commit, enforcing
the requirement that you commit to your updates first.

Details
-------
ADD:
        Insert this new HTLC from proposer to recipient.
SETTLE:
        Recipient collects proposers's committed HTLC with R value.
TIMEOUT:
        Proposer removes committed HTLC it added.
FAIL:
        Recipient removes committed HTLC it received.
UNADD:
        Proposer removes uncommitted HTLC it added.

COMMIT:
        Contains a signature for receiver's commit tx, with all the
        updates included.  Recipient commits updates to its own commit tx,
        and stages those same updates to the other side's commit tx, then
        sends COMPLETE for its own old commit tx.

COMPLETE:
        Completes removal of old commit tx.  Recipient commits updates
        to other side's commit tx, stages those same updates for its own
        commit tx.

So the shortest possible complete exchange looks like:

A               B
ADD->
COMMIT->
                <-COMPLETE
                <-COMMIT
COMPLETE->

Optimizations
-------------
If we want to fail faster, we can add a non-binding ADD_FAIL message,
rather than waiting for a COMMIT.  This would be a hint that we will
FAIL an HTLC as soon as it is committed; recipient may UNADD if it
receives it in time.

Fee Negotiation
---------------
lnd has a fee field in their commit msg, c-lightning uses a fixed fee
negotiation at channel establishment and a FIXME.  The logical place for
fee negotiation is in the COMMIT message, with a requested fee rate and
a range of acceptable values.  Instead of COMPLETE a node may REJECT,
with a fee range; the COMPLETE may then be reattempted.

Similar fee negotiation would be required for mutual close (this isn't
as urgent and so would use a normal fee).

Cheers,
Rusty.