As per lightning-rfc commit 8ee09e749990a11fa53bea03d5961cfde4be4616,
we remove the acks from the protocol now they're no longer needed (and
all the infrastructure).
We also place the commit number in the commit_info where it logically
belongs, removing it from the peer struct.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
From BOLT#2 (rev 8ee09e749990a11fa53bea03d5961cfde4be4616):
Thus each node (conceptually) tracks:
...
3. Two *unacked changesets*: one for the local commitment (their proposals) and one for the remote (our proposals)
4. Two *acked changesets*: one for the local commitment (our proposals, acknowledged) and one for the remote (their proposals, acknowledged).
(Note that an implementation MAY optimize this internally, for
example, pre-applying the changesets in some cases).
In our case, we apply the unacked changes immediately into
staging_cstate, and save them in an unacked_changes array. That array
gets applied to staging_cstate as soon as it's acked (we only allow
one outstanding update_commit, so we only need one array).
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>
While useful for testing, it doesn't make sense to have an explicit commit
command; we should commit whenever there are outstanding changes.
We have a 10ms timer to allow limited batching, however.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Currently this mean --bitcoin-poll; we're going to change the other time
options to block heights anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is just generally good practice. All our other txs are single-input,
so we've not needed to permute inputs before.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
They would sometimes fail under load, if using valgrind. Retry
properly rather than relying on random sleeps. Also, takes "make
check" running time here from 1m31.864s to 1m16.872s.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We use dev-disconnect to convince one node the other has disconnected
(but not vice versa), to get deterministic behaviour. We do this with
one HTLC outstanding, to test the HTLC timeout path.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Once we see an on-chain tx, we ignore the state machine and handle it
as per the onchain.md draft. This specifies a *resolution* for each
output, and we're done when they're irrevocable.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's not quite true: if we offer the anchor, we have a commitinfo
without their signature yet. So make it a pointer again. Since we
always allocate struct commit_info with talz, it starts as a NULL
pointer.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is called when an HTLC times out, and we need to send it back to
ourselves. We also adjust the locktime, since in practice we should
refuse an HTLC less than our locktime.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't report conflicts, just depths. So we report 0 if it's in a
main chain which loses to another, otherwise it's always positive.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
