From rusty at rustcorp.com.au  Thu Feb  4 06:35:03 2016
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Thu, 04 Feb 2016 17:05:03 +1030
Subject: [Lightning-dev] Protocol for multiple in-flight updates.
In-Reply-To: <20160203050135.GA1397@lightning.network>
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>
	<20160203050135.GA1397@lightning.network>
Message-ID: <87r3gt9e5k.fsf@rustcorp.com.au>

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.

Indeed.

I wrote up the protocol as I gleaned it from your explanations, and it
was many words.  But I couldn't quite figure out the commitment steps,
so maybe I'm missing something.

Does your scheme prevent cut-through HTLCs?  A sends B an "add request"
and B wants to send the corresponding "add request" to C immediately to
minimize latency.

If B does this, it has the HTLCa in ADD_STAGED with A, and HTLCb in
ADD_STAGED and C.  C sends B a commit sig which covers the new HTLCb,
but B doesn't want to be locked into HTLCb in case A vanishes before
HTLCa is committed...

Thanks!
Rusty.
PS.  Reading Go is suprisingly nice :)