We always set *matches to false (outside the branch, oops). We also
distinguish the case where we ack from the case where they acked,
which removes a FIXME and makes it work.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We now keep a list of commitment transaction states for "us" and
"them", as well as a "struct channel_state" for staged changes.
We manipulate these structures as we send out packets, receive
packets, or receive acknowledgement of packets. In particular, we
update the other nodes' staging_cstate as we send out our requests,
and update our own staging_cstate are we receive acks. When we
receive a request, we update both (as we immediately send out our
ack).
The RPC output is changed; rather than expose the complexity, we
expose our last committed state: what would happen if we have to drop
to the blockchain now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rather than creating packets then queueing them, call out to functions
which do both. This moves us towards doing more work in those functions
where we send out a request, which is sometimes clearer.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't actually implement closing when we have HTLCs (we should
allow it, as that's what the clearing phase is for), since soon we'll
rewrite HTLC to match the async HTLC protocol of BOLT #2.
Note that this folds the close paths, using a simple check if we have
a close transaction. That's a slight state layer violation, but
reduces code duplication.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If something goes wrong after we've broadcast the anchor tx, we need to use
the commit tx to spend it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We have to sign the commit at this stage, so easiest if peer isn't const
so we can sign it in-place.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This tell us to disarm the INPUT_CLOSE_COMPLETE_TIMEOUT: either we hit
an error and are going to unilateral close, or we received their signature
successfully.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Actually generating the anchor transaction in my implementation
requires interaction with bitcoind, which we want to be async. So add
a callback and a new state to wait for it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We use both union fields idata->btc and idata->htlc, which is clearly
wrong. Have peer_tx_revealed_r_value return the HTLC it's talking
about.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This lets us eliminate struct state_effect altogether (the next patch
removes the now-unused arguments).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We only have one htlc in flight at a time, but sometimes it changes:
particularly when we are lowpriority and a highpriority request comes
in. Handle this using a set of callbacks for htlc handling.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When a unilateral close occurs, we have to watch on-chain ("live")
HTLCs. If the other side spends their HTLC output, we need to grab
the rvalue. If it times out, we need to spend it back to ourselves.
If we get an R value, we need to spend our own HTLC output back to
ourselves.
Because there are multiple HTLCs, this doesn't fit very neatly into a
state machine. We divide into "have htlcs" and "don't have htlcs",
and use a INPUT_NO_MORE_HTLCS once all htlcs are resolved to transition.
Our test harness now tracks individual HTLCs, so we refined some
inputs (in particular, it won't try to complete/timeout an HTLC before
we have any).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell