We keep a "database" for each side's persistent state. Upon restart,
each side tells the other where it was up to, in terms of the number
of commit and revocation messages it receives.
Because only one update can be in flight at a time, we can tell w
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Laolu pointed out that we can't have multiple in flight, since we can't
sign without knowing the next revocation preimage.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Add "nocommitwait" for the two cases we test that, otherwise add
assertions that we never end up dealing with anything other than
the previous commit.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We simply record how many fee changes there are, rather than supporting
a particular level.
Fees are tricky: it's a noop to apply them when incoming, but we apply them
when they've been acked. Unlike HTLC modifications, which are symmetric,
fee updates only apply when returning to the originating node.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell