From joseph at lightning.network  Wed Feb  3 01:33:30 2016
From: joseph at lightning.network (Joseph Poon)
Date: Tue, 2 Feb 2016 17:33:30 -0800
Subject: [Lightning-dev] Protocol for multiple in-flight updates.
In-Reply-To: <877fimmy4t.fsf@rustcorp.com.au>
References: <878u34oi9q.fsf@rustcorp.com.au> <87si1bnc4m.fsf@rustcorp.com.au>
	<20160202072809.GA6119@lightning.network>
	<877fimmy4t.fsf@rustcorp.com.au>
Message-ID: <20160203013330.GA14163@lightning.network>

On Wed, Feb 03, 2016 at 11:02:50AM +1030, Rusty Russell wrote:
> I guess it depends how we count steps.  Each party needs to receive the
> signature for the N+1 commit tx before handing over the Nth revocation
> preimage, but that's the only irreducible constraint isn't it?

Correct, that is a necessity for a secure implementation.

> It's probably simpler to do a three way handshake on every stage, but I
> didn't see that in your protocol?

Unlike a 3-step synchronous commitment, it doesn't wait for the other
party to send their sigantures/revocations and can happen
simultaneously.

Bob's broadcastable Commitment: Alice sends a Signature to Bob. Bob
sends the Revocation of the previous Commitment to Alice.

Alice's broadcastable Commitment: Bob sends a Signature to Alice. Alice
sends to Revocation of the previous Commitment to Bob.

It's that simple. If the HTLC is reflected in both and the previous
commitment(s) is/are revoked, then it's complete.

> If I receive "add request" "add request" "signed commit", how do I know
> what that signatures covers? 

The protocol is still being optimized (deprecating the even/odd
structure, etc.), but the structure is both parties have a list of HTLC
modifications which they want to update. When the modification is
acknowledged by the other party, the HTLC modifcation request is staged
into the next Commitment signature. The inclusion of modifications are
enumerated by including both parties' higest HTLC ID (two of them) in
each Commitment signature message.

> Are you required to wait for my accept/reject message replies before
> commiting?  Or does the commit message include a counter?

Any which is accepted by the other party is included. Two IDs, one for
each party, is included. Two are necessary to allow for timing issues
with HTLC Add responses in-flight not being fully synced up.

> I guess "asynchronous" is a bit nebulous: out-of-order or in-order?  I
> couldn't see a good reason for out-of-order.  Whereas letting both
> sides offer updates in parallel makes good sense for throughput...

In-order. I should have an update in the coming days for lnstate if that
helps (various protocol updates, e.g. fixing exchanging of revocation
hashes, etc.)

-- 
Joseph Poon