From joseph at lightning.network  Tue Feb  9 01:08:20 2016
From: joseph at lightning.network (Joseph Poon)
Date: Mon, 8 Feb 2016 17:08:20 -0800
Subject: [Lightning-dev] Simplified protocol for multiple in-flight
	updates.
In-Reply-To: <878u2vgdoc.fsf@rustcorp.com.au>
References: <878u34oi9q.fsf@rustcorp.com.au> <878u2vgdoc.fsf@rustcorp.com.au>
Message-ID: <20160209010820.GA4488@lightning.network>

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). 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'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). However, I agree if
both nodes are well connected, then this is more optimal if latency is
the primary concern.

-- 
Joseph Poon