From pm+lists at acinq.fr  Fri Apr  1 13:32:15 2016
From: pm+lists at acinq.fr (Pierre)
Date: Fri, 1 Apr 2016 15:32:15 +0200
Subject: [Lightning-dev] Acknowledgements in BOLT #2
In-Reply-To: <87poua8ayh.fsf@rustcorp.com.au>
References: <87poua8ayh.fsf@rustcorp.com.au>
Message-ID: <CAMXsxZNvbbVMkqyhTsKXjx+W9NxAFapGegfgCCH2jiAHLr5oiA@mail.gmail.com>

Hello all,

I noticed in the meantime Rusty recently introduced htlc ids in the
form of absolute "lnd-like 64 bits unique id" vs the previous relative
"order-I-added-them-in" id. I like it better and I think this is
closely related to the issue at hand.

> This is used so we know what the other side has received when they send
>an "update_commit" message, and so we know where to restart the
>conversation after reconnect ("authenticate" message).

To me those two cases should be handled differently because they do
not happen at the same level:
- at the protocol level I would only use the htlc id. It is currently
already used in add/fulfill/fail, so it would make sense to have it in
the update_commit msg as well, instead of relying on the acknowledge
field
- at the transport level (including the reconnect scenario) I would
rely on the acknowledge field to know which messages should be
replayed

Yes it is kind of redundant, and probably less optimal, but it does
separate clearly the transport from the protocol and testing might be
easier.

Also @lnd guys: what's the thing with odd/even htlc ids? Is it just so
that we can use the same keyspace for incoming/outgoing htlcs and
quickly tell the direction of a given htlc, or is there something
else?

Cheers,

Pierre