[Lightning-dev] Protocol for multiple in-flight updates.
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.
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
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...
PS. Reading Go is suprisingly nice :)
More information about the Lightning-dev