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

Rusty Russell rusty at rustcorp.com.au
Thu Feb 4 06:35:03 UTC 2016


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


More information about the Lightning-dev mailing list