[Lightning-dev] Protocol for multiple in-flight updates.

[Rusty Russell]

OK, I've thought about this some more, and here's my strawman protocol.

Importantly, if we pipeline requests, we need something more
sophisticated than "discard if not your turn" for overlaps.  Including
the other side's commitment and retransmitting seems to work.

Each side keeps two sets of "proposals"; mine and yours.  There are two
kinds of proposals, "add to my htlcs" and "remove from your htlcs".

- As part of finalizing a commit tx, we always tell the other side
  what the next revocation hash will be.
  - This simplifies the protocol, as you need the other side's
    revocation hash to produce a signature.
- To add an HTLC, send the proposal.
  - If they decline, fail the HTLC.
  - If they accept, add to my proposals.
- To close an HTLC, send fulfill/timeout/fail:
  - They cannot decline this.
  - Add to my proposals.
- If we receive an add proposal:
  - If we don't want it, send decline.
  - If it's OK, send ack, add the their proposals.
- If we receive a fulfill/timeout/fail:
  - Add to their proposals.

- If we have no outstanding add requests, we can send commit msg
  - Send update_commit: signature of current state including our proposals.
  - If we receive commit_accept with signature and their old revocation preimage.
    - Commit our proposals
    - Send update_commit_complete with our old revocation preimage.
  - If we receive an update_commit message (conflict!)
    - If signature matches current state + their proposals
      - They didn't get our update_commit.
      - Commit their proposals to current state, re-send update_commit
        with that current state + our proposals.
    - Otherwise signature matches current state + their proposals + our proposals
      - Commit their proposals and our proposals to current state.
      - Send update_commit_accept: signature and revocation preimage.
      - Expect update_commit_complete or update_commit_accept.
- If we receive an update_commit message (and we've not sent one!)
  - Commit "their changes" to current state.
  - Send update_commit_accept: signature and revocation preimage.
  - Expect update_commit_complete.

Packets involved:
        update_add_htlc: [new htlc details]
                update_decline_htlc: [reason]
                update_accept_htlc
        update_fulfill_htlc: [r value]
        update_timeout_htlc: [htlc rhash]
        update_fail_htlc: [htlc rhash]

        update_commit: [sig]
        update_commit_accept: [sig] [old commit preimage] [next commit hash]
        update_commit_complete: [old commit preimage] [next commit hash]

Cheers,
Rusty.
PS.  Yes, it's complex.  Better way welcome...