From rusty at rustcorp.com.au  Tue Feb  9 04:30:24 2016
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Tue, 09 Feb 2016 15:00:24 +1030
Subject: [Lightning-dev] Simplified protocol for multiple in-flight
	updates.
In-Reply-To: <20160209010820.GA4488@lightning.network>
References: <878u34oi9q.fsf@rustcorp.com.au> <878u2vgdoc.fsf@rustcorp.com.au>
	<20160209010820.GA4488@lightning.network>
Message-ID: <87zivazesf.fsf@rustcorp.com.au>

Joseph Poon <joseph at lightning.network> writes:
> On Tue, Feb 09, 2016 at 06:47:07AM +1030, Rusty Russell wrote:
>>         Eliminating all acknowledgements makes for a much simpler
>> protocol.
>
> For adding HTLCs, this may be an option, but there are some tradeoffs.
> The downside of doing this is that it's uncertain whether the other
> party has received the message. Essentially, the moment the packets are
> sent over the wire, it should be assumed the other party can broadcast
> (TCP SACKs cannot be relied upon, of course).

Only once you've sent the signature; they ack the signature with the old
revocation preimage.  It's a single-RTT window.

> To remove the HTLC securely, it requires removing the HTLC,
> committing, and then the other party revokes the prior commitment. If
> the ratio of success/failure is high enough it can be worth it.
> This may have some disadvantages with
> intermittently connected nodes, as requiring confirmation has a
> significantly smaller time window for non-responsive payments.

I don't think anything can save a node which goes offline in the middle
of an exchange.  Not sure this makes it worse?

> I'm
> optimizing against payment failure on the ADD side, as failure may
> require a re-route in the opposite direction to do a full cancel with a
> non-responsive node in multi-hop payments (as an add request/accept
> structure has lower time windows for going offline).

I'm not convinced the re-route scheme will be used in practice.  We're
probably going to need to distinguish (for fee reasons) payments
expected to resolve quickly, and those expected to take a long time.
Re-routing in the opposite direction is worst case: it ties up funds for
a long time with no actual likely redemption, thus would require a large
up-front fee.

I think in practice, if a node goes down with possibly-live HTLCs, those
HTLCs get delayed.  The node loses channels, too, so it's not free for
them either.

> However, I agree if
> both nodes are well connected, then this is more optimal if latency is
> the primary concern.

This offers 3x inter-node latency, which is optimal AFAICT (I know I
talked about cut-through, but while possible for route discovery it
turns out not to help total end-to-end commit latency).

As I said before, I was unsure on your commitment scheme, so maybe I'm
missing a trick?

Thanks!
Rusty.