From rusty at rustcorp.com.au  Thu Mar 31 23:49:26 2016
From: rusty at rustcorp.com.au (Rusty Russell)
Date: Fri, 01 Apr 2016 10:19:26 +1030
Subject: [Lightning-dev] Acknowledgements in BOLT #2
Message-ID: <87poua8ayh.fsf@rustcorp.com.au>

Hi all!

        Pierre queried the placement of acknowlegements in BOLT #2; I
share his concerns, but wanted to document them here too.

        The current draft (which I've implemented, and seems to work as
of yesterday) has a header with an "acknowledge" field:

(BOLT-encryption):
* `acknowledge`: an 8-byte little-endian field indicating the number of non-`authenticate` messages received and processed so far.

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).

The current spec requires that acks never go backwards, meaning in
practice an implementation needs to write to disk persistently before
*every* new packet sent.

If we move the "ack" back into the update_commit/authenticatate messages
(I had this originally), I think we can have the spec say that on
reconnect you retransmit from previous received update_revocation.  And
fee updates should Just Work too.  There's also an implied "ack" in the
update_revocation message (which has to correspond to the
update_commit).  One will need to be added to the "authenticate"
message, too, which is used for connection re-establishment.

It's not a big code change: it's logically implemented as callbacks when
a packet is acked.  That just means they'll just fire all at once when
we receive a update_commit / update_revocation packet...

I'll now try implementing that, and report back if I've missed anything
:)

Cheers,
Rusty.