There's no real reason to avoid commands for the next commit; this has
the benefit that we can remove the infrastructure to queue commands.
The only exceptions are the commit command and the opening phase.
We still only allow one commit at a time, but that's mainly run off a
timer which can try again later. For the JSONRPC API used for
testing, we can simply fail the commit if one is in progress.
For opening we add an explicit peer_open_complete() call in place of
using the command infrastructure.
Commands are now outside the state machine altogether: we simply have
it return the new state instead of the command status. The JSONRPC
functions can also now run commands directly.
This removes the idea of "peercond" as well: you can simply examine
the states to determine whether an input is valid. There are
fine-grained helpers for this now, too.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We already removed the on-chain states, now we remove the "clearing" state
(which wasn't fully implemented anyway).
This turns into two smaller state machines: one for clearing, which
still allows HTLCs to be failed and fulfilled, and one for mutual
close negotiation which only allows close_signature messages.
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>
There's no reason to, it's a simple p2wpkh to our key.
We still spend the "to-us" from our commit tx, since it could be
theoretically be stolen by the revocation value, and it's a complex
p2wsh which a normal wallet won't have the information to spend.
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>
We used to have a hacky close timeout which would immediately fire
when we'd closed because the connection was down. Far better to have
a specific "connection lost" input, and have it respond like CMD_CLOSE.
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>
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>
This is conceptually cleaner, especially since it means we're running
a command until we're set up (which prevents other commands, so no
special case needed).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We'd expect stop_commands to stop all commands, but we (ab)used
CMD_SEND_HTLC_FULFILL to send us R values even in closing state.
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