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

[Rusty Russell]

Joseph Poon <joseph at lightning.network> writes:
> On Wed, Feb 03, 2016 at 03:05:33PM +1030, Rusty Russell wrote:
>> 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?
>
> Yeah, it's more like a request "staging" ID. The "counter" aspect
> requires two counters (one for each originator of the request). Two IDs
> sent in the commitment message allow for simultaneous action on
> accept/reject/etc, whereas only one would require a lock on
> accepting/rejecting modifications.
>
> Minor note which has the potential to be overlooked: It's a hard
> requirement that all messages sent are in order, and if the replyer
> skips the requester's Add Requests when replying, the skipped are
> assumed to be request rejections (or an outright channel closeout) since
> it should never happen -- this is to enforce accept/reject order, as we
> need to know which modifications are included in the
> signature/transaction and not have that change after-the-fact.

I would simply disallow skipping as a protocol violation.

I think this approach also leads neatly to an gentler close protocol:
sending close would simply imply the initiator would send no more adds,
and reject all received.  It could take a while to clean out all the
remaining HTLCs for mutual close (assuming we still don't support close
with htlcs), but at least the other side knows what we're doing and
can open new channels to replace capacity if it wants to.

I'm going to try to document your protocol in another mail, let's see
how close I get this time!

Thanks,
Rusty.