From rusty at rustcorp.com.au  Thu Oct 13 19:15:36 2016
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Fri, 14 Oct 2016 05:45:36 +1030
Subject: [Lightning-dev] Allowing acknowledgement via commit messages
Message-ID: <87eg3k83hj.fsf@rustcorp.com.au>

Hi all,

        I've been trying to write the spec part about the
propose/commitsig/revoke cycle.  We agreed that the commitsig message
would include an extra "I included these updates from you" field.  This
has two side-effects I hadn't appreciated.

1. Without it, the state of updates is always linear:

        RECEIVER-PENDING: update pending on receiver side
        RECEIVER-COMMITTED: update included in receiver commit tx
        RECEIVER-LOCKEDIN-SENDER-PENDING: and previous receiver commit
                        tx preimage revealed, update now pending on sender.
        RECEIVER-LOCKEDIN-SENDER-COMMITTED: update included in sender commit tx
        BOTH-LOCKEDIN: and previous sender commit tx preimage revealed.

   This means you trigger forwarding on the final state, since both sides
   are fully committed at that point.

   With the ability to push proposed received updates to the other side
   by including them in your own commit message, these changes are
   unordered.  It's no longer a linear state machine (and certainly has
   many more states).

2. We can't do fail-fast in future.  There was an idea that if the
   receiver knew it was going to immediately fail an HTLC, it could
   reply with a "this HTLC is going to fail"; if the sender receives
   that message before it sends "commit", it can send a "undo that
   HTLC add" and cancel it out immediately.  It's an easy extension.

   If the receiver can push the uncommitted changes into the sender's
   commit tx, the receiver can't "undo" before commit, and this scheme
   fails.

I feel bound by decisions we already made, but I am struggling to write
the spec clearly enough with this addition.

Thoughts?
Rusty.