daemon: move unacked queue into commit_info struct.

We're about to allow changes while we're waiting for a commit ack.
This means we can't have a single "unacked changes" queue; when we
receive the revocation reply, we need to apply the unacked changes
known at the time we sent the commit, not any we've created since
then.

Note that we still only have a single staged_commit; we never have two
outstanding commits, since for simplicity we will still block
following update_commit pending the reply to the current one.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell
2016-05-26 15:25:25 +09:30
parent 36fc62ab81
commit d4862938c8
3 changed files with 39 additions and 38 deletions

View File

@@ -2249,9 +2249,9 @@ const struct bitcoin_tx *bitcoin_anchor(struct peer *peer)
void add_unacked(struct peer_visible_state *which,
const union htlc_staging *stage)
{
size_t n = tal_count(which->unacked_changes);
tal_resize(&which->unacked_changes, n+1);
which->unacked_changes[n] = *stage;
size_t n = tal_count(which->commit->unacked_changes);
tal_resize(&which->commit->unacked_changes, n+1);
which->commit->unacked_changes[n] = *stage;
}
/* Sets up the initial cstate and commit tx for both nodes: false if
@@ -2303,9 +2303,6 @@ bool setup_first_commit(struct peer *peer)
peer->local.staging_cstate = copy_funding(peer, peer->local.commit->cstate);
peer->remote.staging_cstate = copy_funding(peer, peer->remote.commit->cstate);
peer->local.unacked_changes = tal_arr(peer, union htlc_staging, 0);
peer->remote.unacked_changes = tal_arr(peer, union htlc_staging, 0);
return true;
}