In recv_rev() previously all unacked_local_updates were deleted
as it was assumed that all of them have been acked at that point by
the revoke_and_ack itself. However this is not necessarily the case:
see new test case.
renamed log['unacked_local_updates'] to log['unacked_local_updates2']
to avoid breaking existing wallet files
Even if we haven't signed them yet (did not send commitment_signed).
Alternatively, if they are not yet signed, we could discard them here,
like we do already for remote updates above (chan.hm.discard_unsigned_remote_updates).
One of these two options must be done, and before this commit we were not doing either.
"current" used to be "oldest_unrevoked"; and pending was "oldest_unrevoked + 1"
but this was very confusing...
so now we have "oldest_unrevoked", "latest", and "next"
where "next" is "latest + 1"
"oldest_unrevoked" and "latest" are either the same or are offset by 1
(but caller should know which one they need)
rm "got_sig_for_next" - it was a redundant sanity check, that really
just complicated things
rm "local_commitment", "remote_commitment", "set_local_commitment",
"set_remote_commitment" - just use "get_latest_commitment" instead
Replay un-acked local updates (including commitment_signed) byte-for-byte.
If we have sent them a commitment signature that they "lost" (due to disconnect),
we need to make sure we replay the same local updates, as otherwise they could
end up with two (or more) signed valid commitment transactions at the same ctn.
Multiple valid ctxs at the same ctn is a major headache for pre-signing spending txns,
e.g. for watchtowers, hence we must ensure these ctxs coincide.
SomberNight
ThomasV