[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