From rusty at rustcorp.com.au  Wed Feb  3 00:32:50 2016
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Wed, 03 Feb 2016 11:02:50 +1030
Subject: [Lightning-dev] Protocol for multiple in-flight updates.
In-Reply-To: <20160202072809.GA6119@lightning.network>
References: <878u34oi9q.fsf@rustcorp.com.au> <87si1bnc4m.fsf@rustcorp.com.au>
	<20160202072809.GA6119@lightning.network>
Message-ID: <877fimmy4t.fsf@rustcorp.com.au>

Joseph Poon <joseph at lightning.network> writes:
> Hi Rusty,
>
> For synchronous across-the-wire commit steps, 3 steps is a good idea and
> more secure than 2 steps for the commit transaction.

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?

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

> However, the nice thing about keeping everything asynchronous is it
> simplifies orchestration and no locking across-the-wire. We have a
> preliminary explanation on the git repo in the README.md file.

Yes, but it was a bit dense.  Or I am :)

If I receive "add request" "add request" "signed commit", how do I know
what that signatures covers?  Both new htlcs?  Are you required to wait
for my accept/reject message replies before commiting?  Or does the
commit message include a counter?

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...

Thanks!
Rusty.