From joseph at lightning.network  Wed Feb  3 05:01:35 2016
From: joseph at lightning.network (Joseph Poon)
Date: Tue, 2 Feb 2016 21:01:35 -0800
Subject: [Lightning-dev] Protocol for multiple in-flight updates.
In-Reply-To: <87io26becq.fsf@rustcorp.com.au>
References: <878u34oi9q.fsf@rustcorp.com.au> <87si1bnc4m.fsf@rustcorp.com.au>
	<20160202072809.GA6119@lightning.network>
	<877fimmy4t.fsf@rustcorp.com.au>
	<20160203013330.GA14163@lightning.network>
	<87io26becq.fsf@rustcorp.com.au>
Message-ID: <20160203050135.GA1397@lightning.network>

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.

-- 
Joseph Poon