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

Rusty Russell rusty at rustcorp.com.au
Wed Feb 3 00:32:50 UTC 2016


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.


More information about the Lightning-dev mailing list