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

[Rusty Russell]

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

>> 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
a counter?

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

Right.

>> 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! :)

Cheers,
Rusty.