[Lightning-dev] Protocol for multiple in-flight updates.
rusty at rustcorp.com.au
Wed Feb 3 04:35:33 UTC 2016
Joseph Poon <joseph at lightning.network> writes:
> 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.
Ah, I think I finally understand! I was artificially linking the two
sides' commit transactions, but there's really no reason to. As you
say, once you've included an HTLC in both sides in any form, it's
>> 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.
Right, so "this signature covers you up to X me up to Y". That resolves
the in-flight issue.
But isn't that more a request ID rather than an HTLC ID? Since requests
can include removing HTLCs as well? And doesn't that simply degrade to
>> 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.)
Thanks, I feel smarter now! :)
More information about the Lightning-dev