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>
This is simpler for database representation, and also allows simple
bit-tests for what is happening to a HTLC (eg. am I committed to it?
Are you? etc.)
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>
Since our pre-change state is always the same as the previous step's
post-change state, we can simply keep a pointer, with a dummy empty
state for the initial one.
We could function-wrap it, but this change is even simpler.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This finished the previous patch by simply copying funding_next to funding
when we want to apply changes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This makes it easier to test for validity, though we still double-check
that a change doesn't overlap previous changes.
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