[Lightning-dev] Simplified protocol for multiple in-flight updates.
rusty at rustcorp.com.au
Tue Feb 9 04:30:24 UTC 2016
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
> 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?
> 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
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
> 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?
More information about the Lightning-dev