mirrors/core-lightning
1
0
Fork 0
mirror of https://github.com/ElementsProject/lightning.git synced 2024-11-19 18:11:28 +01:00
Code Issues Projects Releases Wiki Activity
ab38fd7542
core-lightning/state.c

327 lines
9.7 KiB
C
Raw Normal View History

state: handle on-chain HTLCs. 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>
2015-09-25 04:21:18 +02:00
#include <ccan/build_assert/build_assert.h>
packets.c: accept_pkt_* should do less state-mangling. Move other logic into caller, but it's not complete (it still needs to check some things, and still records some results). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:45 +02:00
#include <daemon/lightningd.h>
daemon: log all state changes the same way. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-05 06:53:34 +02:00
#include <daemon/log.h>
daemon/packets.h: create from prototypes which were in state.h. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:45 +02:00
#include <daemon/packets.h>
state: include daemon/peer (only if !TEST_COVERAGE). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:49 +01:00
#include <daemon/peer.h>
packets.c: queue_pkt_* only creates and sends packets. Move other logic into caller: it grew this way because we used to have a centralized "state" machine which knew nothing of these internal details. But now we want to re-queue packets on reconnect, we really want these routines to be idempotent. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:45 +02:00
#include <daemon/secrets.h>
daemon: log all state changes the same way. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-05 06:53:34 +02:00
#include <names.h>
state: order headers correctly. make check-source will complain once we include state.c. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:46 +01:00
#include <state.h>
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
static enum state next_state(struct peer *peer,
const enum state_input input,
const enum state state)
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
{
state: set peer->state directly. Instead of new_state effect. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:46 +01:00
assert(peer->state != state);
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
return state;
state: set peer->state directly. Instead of new_state effect. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:46 +01:00
}
state: make tx arguments const. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:47 +01:00
static void queue_tx_broadcast(const struct bitcoin_tx **broadcast,
const struct bitcoin_tx *tx)
state: return tx to be queued directly. Instead of effect->broadcast_tx. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:47 +01:00
{
assert(!*broadcast);
assert(tx);
*broadcast = tx;
}
packets.c: queue_pkt_* only creates and sends packets. Move other logic into caller: it grew this way because we used to have a centralized "state" machine which knew nothing of these internal details. But now we want to re-queue packets on reconnect, we really want these routines to be idempotent. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:45 +02:00
static void send_open_pkt(struct peer *peer,
OpenChannel__AnchorOffer anchor)
{
/* Set up out commit info now: rest gets done in setup_first_commit
* once anchor is established. */
peer->local.commit = new_commit_info(peer);
peer->local.commit->revocation_hash = peer->local.next_revocation_hash;
peer_get_revocation_hash(peer, 1, &peer->local.next_revocation_hash);
queue_pkt_open(peer, anchor);
}
packets.c: accept_pkt_* should do less state-mangling. Move other logic into caller, but it's not complete (it still needs to check some things, and still records some results). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:45 +02:00
static Pkt *init_from_pkt_open(struct peer *peer, const Pkt *pkt)
{
struct commit_info *ci = new_commit_info(peer);
Pkt *err;
err = accept_pkt_open(peer, pkt, &ci->revocation_hash,
&peer->remote.next_revocation_hash);
if (err)
return err;
/* Set up their commit info now: rest gets done in setup_first_commit
* once anchor is established. */
peer->remote.commit = ci;
/* Witness script for anchor. */
peer->anchor.witnessscript
= bitcoin_redeem_2of2(peer, peer->dstate->secpctx,
&peer->local.commitkey,
&peer->remote.commitkey);
return NULL;
}
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
enum state state(struct peer *peer,
const enum state_input input,
daemon: remove normal operation loop from state.c It's now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-06-28 23:19:20 +02:00
const Pkt *pkt,
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
const struct bitcoin_tx **broadcast)
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
{
Pkt *err;
state: return status of current command. We temporarily move effect to the end of the arg list: we'll get rid of it eventually. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:46 +01:00
state: return tx to be queued directly. Instead of effect->broadcast_tx. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:47 +01:00
*broadcast = NULL;
state: return Pkt to be queued directly. Instead of effect->send_pkt. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:47 +01:00
state: set peer->state directly. Instead of new_state effect. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:46 +01:00
switch (peer->state) {
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
/*
* Initial channel opening states.
*/
state: use STATE_INIT and separate inputs to decide on anchor. 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>
2016-01-21 21:11:46 +01:00
case STATE_INIT:
if (input_is(input, CMD_OPEN_WITH_ANCHOR)) {
packets.c: queue_pkt_* only creates and sends packets. Move other logic into caller: it grew this way because we used to have a centralized "state" machine which knew nothing of these internal details. But now we want to re-queue packets on reconnect, we really want these routines to be idempotent. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:45 +02:00
send_open_pkt(peer,
OPEN_CHANNEL__ANCHOR_OFFER__WILL_CREATE_ANCHOR);
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
return next_state(peer, input,
state: use STATE_INIT and separate inputs to decide on anchor. 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>
2016-01-21 21:11:46 +01:00
STATE_OPEN_WAIT_FOR_OPEN_WITHANCHOR);
} else if (input_is(input, CMD_OPEN_WITHOUT_ANCHOR)) {
packets.c: queue_pkt_* only creates and sends packets. Move other logic into caller: it grew this way because we used to have a centralized "state" machine which knew nothing of these internal details. But now we want to re-queue packets on reconnect, we really want these routines to be idempotent. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:45 +02:00
send_open_pkt(peer,
OPEN_CHANNEL__ANCHOR_OFFER__WONT_CREATE_ANCHOR);
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
return next_state(peer, input,
state: use STATE_INIT and separate inputs to decide on anchor. 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>
2016-01-21 21:11:46 +01:00
STATE_OPEN_WAIT_FOR_OPEN_NOANCHOR);
}
break;
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
case STATE_OPEN_WAIT_FOR_OPEN_NOANCHOR:
if (input_is(input, PKT_OPEN)) {
packets.c: accept_pkt_* should do less state-mangling. Move other logic into caller, but it's not complete (it still needs to check some things, and still records some results). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:45 +02:00
err = init_from_pkt_open(peer, pkt);
state: use STATE_INIT and separate inputs to decide on anchor. 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>
2016-01-21 21:11:46 +01:00
if (err) {
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, err->error->problem);
state: trim unused states. Now we never enter the state machine if we're dealing with on-chain transactions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-04 08:44:22 +02:00
goto err_breakdown;
state: use STATE_INIT and separate inputs to decide on anchor. 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>
2016-01-21 21:11:46 +01:00
}
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
return next_state(peer, input, STATE_OPEN_WAIT_FOR_ANCHOR);
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
} else if (input_is_pkt(input)) {
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, "unexpected packet");
state: trim unused states. Now we never enter the state machine if we're dealing with on-chain transactions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-04 08:44:22 +02:00
goto unexpected_pkt;
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
}
break;
case STATE_OPEN_WAIT_FOR_OPEN_WITHANCHOR:
if (input_is(input, PKT_OPEN)) {
packets.c: accept_pkt_* should do less state-mangling. Move other logic into caller, but it's not complete (it still needs to check some things, and still records some results). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:45 +02:00
err = init_from_pkt_open(peer, pkt);
state: use STATE_INIT and separate inputs to decide on anchor. 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>
2016-01-21 21:11:46 +01:00
if (err) {
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, err->error->problem);
state: trim unused states. Now we never enter the state machine if we're dealing with on-chain transactions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-04 08:44:22 +02:00
goto err_breakdown;
state: use STATE_INIT and separate inputs to decide on anchor. 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>
2016-01-21 21:11:46 +01:00
}
state: add async anchor creation. 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>
2016-01-21 21:11:47 +01:00
bitcoin_create_anchor(peer, BITCOIN_ANCHOR_CREATED);
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
return next_state(peer, input,
state: add async anchor creation. 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>
2016-01-21 21:11:47 +01:00
STATE_OPEN_WAIT_FOR_ANCHOR_CREATE);
} else if (input_is_pkt(input)) {
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, "unexpected packet");
state: trim unused states. Now we never enter the state machine if we're dealing with on-chain transactions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-04 08:44:22 +02:00
goto unexpected_pkt;
state: add async anchor creation. 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>
2016-01-21 21:11:47 +01:00
}
break;
case STATE_OPEN_WAIT_FOR_ANCHOR_CREATE:
if (input_is(input, BITCOIN_ANCHOR_CREATED)) {
packets.c: queue_pkt_* only creates and sends packets. Move other logic into caller: it grew this way because we used to have a centralized "state" machine which knew nothing of these internal details. But now we want to re-queue packets on reconnect, we really want these routines to be idempotent. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:45 +02:00
/* This shouldn't happen! */
if (!setup_first_commit(peer)) {
err = pkt_err(peer,
"Own anchor has insufficient funds");
peer_open_complete(peer, err->error->problem);
goto err_breakdown;
}
state: queue packets directly. 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>
2016-03-30 08:27:18 +02:00
queue_pkt_anchor(peer);
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
return next_state(peer, input,
state: simplify effect. Make it a linked list of effects, rather than one big union. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:45 +01:00
STATE_OPEN_WAIT_FOR_COMMIT_SIG);
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
} else if (input_is_pkt(input)) {
state: add async anchor creation. 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>
2016-01-21 21:11:47 +01:00
bitcoin_release_anchor(peer, BITCOIN_ANCHOR_CREATED);
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, "unexpected packet");
state: trim unused states. Now we never enter the state machine if we're dealing with on-chain transactions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-04 08:44:22 +02:00
goto unexpected_pkt;
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
}
break;
case STATE_OPEN_WAIT_FOR_ANCHOR:
if (input_is(input, PKT_OPEN_ANCHOR)) {
daemon: remove normal operation loop from state.c It's now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-06-28 23:19:20 +02:00
err = accept_pkt_anchor(peer, pkt);
state: use STATE_INIT and separate inputs to decide on anchor. 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>
2016-01-21 21:11:46 +01:00
if (err) {
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, err->error->problem);
state: trim unused states. Now we never enter the state machine if we're dealing with on-chain transactions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-04 08:44:22 +02:00
goto err_breakdown;
state: use STATE_INIT and separate inputs to decide on anchor. 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>
2016-01-21 21:11:46 +01:00
}
packets.c: accept_pkt_* should do less state-mangling. Move other logic into caller, but it's not complete (it still needs to check some things, and still records some results). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:45 +02:00
if (!setup_first_commit(peer)) {
err = pkt_err(peer, "Insufficient funds for fee");
peer_open_complete(peer, err->error->problem);
goto err_breakdown;
}
packets.c: queue_pkt_* only creates and sends packets. Move other logic into caller: it grew this way because we used to have a centralized "state" machine which knew nothing of these internal details. But now we want to re-queue packets on reconnect, we really want these routines to be idempotent. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:45 +02:00
log_debug_struct(peer->log, "Creating sig for %s",
struct bitcoin_tx,
peer->remote.commit->tx);
log_add_struct(peer->log, " using key %s",
struct pubkey, &peer->local.commitkey);
peer->remote.commit->sig = tal(peer->remote.commit,
struct bitcoin_signature);
peer->remote.commit->sig->stype = SIGHASH_ALL;
peer_sign_theircommit(peer, peer->remote.commit->tx,
&peer->remote.commit->sig->sig);
peer: save txid -> commit_num mapping. This is in preparation for placing it in a database. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:45 +02:00
peer_add_their_commit(peer, &peer->remote.commit->txid,
peer->remote.commit->commit_num);
packets.c: queue_pkt_* only creates and sends packets. Move other logic into caller: it grew this way because we used to have a centralized "state" machine which knew nothing of these internal details. But now we want to re-queue packets on reconnect, we really want these routines to be idempotent. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:45 +02:00
state: queue packets directly. 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>
2016-03-30 08:27:18 +02:00
queue_pkt_open_commit_sig(peer);
peer: record depth at which anchor tx is considered deep enough. This makes it explicit, which is better for storing in a database (before it was just what watch callback, plus peer->local.mindepth). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:45 +02:00
peer_watch_anchor(peer,
peer->local.mindepth,
state: add callbacks for adding/removing watches. 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>
2016-01-21 21:11:47 +01:00
BITCOIN_ANCHOR_DEPTHOK,
state: trim unused states. Now we never enter the state machine if we're dealing with on-chain transactions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-04 08:44:22 +02:00
BITCOIN_ANCHOR_TIMEOUT);
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
return next_state(peer, input,
state: simplify effect. Make it a linked list of effects, rather than one big union. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:45 +01:00
STATE_OPEN_WAITING_THEIRANCHOR);
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
} else if (input_is_pkt(input)) {
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, "unexpected packet");
state: trim unused states. Now we never enter the state machine if we're dealing with on-chain transactions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-04 08:44:22 +02:00
goto unexpected_pkt;
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
}
break;
case STATE_OPEN_WAIT_FOR_COMMIT_SIG:
if (input_is(input, PKT_OPEN_COMMIT_SIG)) {
packets.c: accept_pkt_* should do less state-mangling. Move other logic into caller, but it's not complete (it still needs to check some things, and still records some results). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:45 +02:00
err = accept_pkt_open_commit_sig(peer, pkt,
&peer->local.commit->sig);
if (!err &&
!check_tx_sig(peer->dstate->secpctx,
peer->local.commit->tx, 0,
NULL, 0,
peer->anchor.witnessscript,
&peer->remote.commitkey,
peer->local.commit->sig))
err = pkt_err(peer, "Bad signature");
state: use STATE_INIT and separate inputs to decide on anchor. 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>
2016-01-21 21:11:46 +01:00
if (err) {
state: add async anchor creation. 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>
2016-01-21 21:11:47 +01:00
bitcoin_release_anchor(peer, INPUT_NONE);
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, err->error->problem);
state: trim unused states. Now we never enter the state machine if we're dealing with on-chain transactions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-04 08:44:22 +02:00
goto err_breakdown;
state: use STATE_INIT and separate inputs to decide on anchor. 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>
2016-01-21 21:11:46 +01:00
}
protocol: use separate ack packet. It's a data-leak to send ack before we have verified identity of peer. Plus, we can't send it until we know which peer it is, anyway! Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:46 +02:00
peer->their_commitsigs++;
state: queue packets directly. 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>
2016-03-30 08:27:18 +02:00
queue_tx_broadcast(broadcast, bitcoin_anchor(peer));
state: add callbacks for adding/removing watches. 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>
2016-01-21 21:11:47 +01:00
peer_watch_anchor(peer,
peer: record depth at which anchor tx is considered deep enough. This makes it explicit, which is better for storing in a database (before it was just what watch callback, plus peer->local.mindepth). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-08-18 06:53:45 +02:00
peer->local.mindepth,
state: add callbacks for adding/removing watches. 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>
2016-01-21 21:11:47 +01:00
BITCOIN_ANCHOR_DEPTHOK,
state: trim unused states. Now we never enter the state machine if we're dealing with on-chain transactions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-04 08:44:22 +02:00
INPUT_NONE);
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
return next_state(peer, input,
state: return status of current command. We temporarily move effect to the end of the arg list: we'll get rid of it eventually. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:46 +01:00
STATE_OPEN_WAITING_OURANCHOR);
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
} else if (input_is_pkt(input)) {
state: add async anchor creation. 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>
2016-01-21 21:11:47 +01:00
bitcoin_release_anchor(peer, INPUT_NONE);
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, "unexpected packet");
state: trim unused states. Now we never enter the state machine if we're dealing with on-chain transactions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-04 08:44:22 +02:00
goto unexpected_pkt;
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
}
break;
case STATE_OPEN_WAITING_OURANCHOR:
state: add _THEYCOMPLETED states to reflect receiving PKT_OPEN_COMPLETE This is cleaner than deferring the packet receive and asking for it later. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:46 +01:00
if (input_is(input, PKT_OPEN_COMPLETE)) {
daemon: remove normal operation loop from state.c It's now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-06-28 23:19:20 +02:00
err = accept_pkt_open_complete(peer, pkt);
state: explicit callback to check pkt_open_complete. For now, this always succeeds, but include the hook for completeness. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-03-08 01:09:15 +01:00
if (err) {
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, err->error->problem);
state: trim unused states. Now we never enter the state machine if we're dealing with on-chain transactions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-04 08:44:22 +02:00
goto err_breakdown;
state: explicit callback to check pkt_open_complete. For now, this always succeeds, but include the hook for completeness. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-03-08 01:09:15 +01:00
}
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
return next_state(peer, input,
state: add _THEYCOMPLETED states to reflect receiving PKT_OPEN_COMPLETE This is cleaner than deferring the packet receive and asking for it later. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:46 +01:00
STATE_OPEN_WAITING_OURANCHOR_THEYCOMPLETED);
}
/* Fall thru */
case STATE_OPEN_WAITING_OURANCHOR_THEYCOMPLETED:
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
if (input_is(input, BITCOIN_ANCHOR_DEPTHOK)) {
state: queue packets directly. 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>
2016-03-30 08:27:18 +02:00
queue_pkt_open_complete(peer);
state: set peer->state directly. Instead of new_state effect. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:46 +01:00
if (peer->state == STATE_OPEN_WAITING_OURANCHOR_THEYCOMPLETED) {
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, NULL);
return next_state(peer, input, STATE_NORMAL);
state: add _THEYCOMPLETED states to reflect receiving PKT_OPEN_COMPLETE This is cleaner than deferring the packet receive and asking for it later. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:46 +01:00
}
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
return next_state(peer, input,
state: simplify effect. Make it a linked list of effects, rather than one big union. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:45 +01:00
STATE_OPEN_WAIT_FOR_COMPLETE_OURANCHOR);
protocol: implement close as per BOLT #2. 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>
2016-03-24 02:39:41 +01:00
} else if (input_is(input, PKT_CLOSE_CLEARING)) {
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, "Received PKT_CLOSE_CLEARING");
protocol: implement close as per BOLT #2. 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>
2016-03-24 02:39:41 +01:00
goto accept_clearing;
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
} else if (input_is_pkt(input)) {
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, "unexpected packet");
state: cleanup after anchor has been transmitted. 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>
2016-03-08 01:08:15 +01:00
goto unexpected_pkt;
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
}
break;
case STATE_OPEN_WAITING_THEIRANCHOR:
state: add _THEYCOMPLETED states to reflect receiving PKT_OPEN_COMPLETE This is cleaner than deferring the packet receive and asking for it later. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:46 +01:00
if (input_is(input, PKT_OPEN_COMPLETE)) {
daemon: remove normal operation loop from state.c It's now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-06-28 23:19:20 +02:00
err = accept_pkt_open_complete(peer, pkt);
state: explicit callback to check pkt_open_complete. For now, this always succeeds, but include the hook for completeness. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-03-08 01:09:15 +01:00
if (err) {
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, err->error->problem);
state: trim unused states. Now we never enter the state machine if we're dealing with on-chain transactions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-04 08:44:22 +02:00
goto err_breakdown;
state: explicit callback to check pkt_open_complete. For now, this always succeeds, but include the hook for completeness. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-03-08 01:09:15 +01:00
}
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
return next_state(peer, input,
state: add _THEYCOMPLETED states to reflect receiving PKT_OPEN_COMPLETE This is cleaner than deferring the packet receive and asking for it later. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:46 +01:00
STATE_OPEN_WAITING_THEIRANCHOR_THEYCOMPLETED);
}
/* Fall thru */
case STATE_OPEN_WAITING_THEIRANCHOR_THEYCOMPLETED:
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
if (input_is(input, BITCOIN_ANCHOR_TIMEOUT)) {
/* Anchor didn't reach blockchain in reasonable time. */
state: queue packets directly. 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>
2016-03-30 08:27:18 +02:00
queue_pkt_err(peer, pkt_err(peer, "Anchor timed out"));
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
return next_state(peer, input, STATE_ERR_ANCHOR_TIMEOUT);
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
} else if (input_is(input, BITCOIN_ANCHOR_DEPTHOK)) {
state: queue packets directly. 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>
2016-03-30 08:27:18 +02:00
queue_pkt_open_complete(peer);
state: set peer->state directly. Instead of new_state effect. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:46 +01:00
if (peer->state == STATE_OPEN_WAITING_THEIRANCHOR_THEYCOMPLETED) {
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, NULL);
return next_state(peer, input, STATE_NORMAL);
state: add _THEYCOMPLETED states to reflect receiving PKT_OPEN_COMPLETE This is cleaner than deferring the packet receive and asking for it later. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:46 +01:00
}
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
return next_state(peer, input,
state: return status of current command. We temporarily move effect to the end of the arg list: we'll get rid of it eventually. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:46 +01:00
STATE_OPEN_WAIT_FOR_COMPLETE_THEIRANCHOR);
protocol: implement close as per BOLT #2. 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>
2016-03-24 02:39:41 +01:00
} else if (input_is(input, PKT_CLOSE_CLEARING)) {
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, "Received PKT_CLOSE_CLEARING");
protocol: implement close as per BOLT #2. 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>
2016-03-24 02:39:41 +01:00
goto accept_clearing;
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
} else if (input_is_pkt(input)) {
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, "unexpected packet");
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
goto unexpected_pkt;
}
break;
case STATE_OPEN_WAIT_FOR_COMPLETE_OURANCHOR:
case STATE_OPEN_WAIT_FOR_COMPLETE_THEIRANCHOR:
if (input_is(input, PKT_OPEN_COMPLETE)) {
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
/* Ready for business! */
peer_open_complete(peer, NULL);
return next_state(peer, input, STATE_NORMAL);
protocol: implement close as per BOLT #2. 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>
2016-03-24 02:39:41 +01:00
} else if (input_is(input, PKT_CLOSE_CLEARING)) {
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, "Received PKT_CLOSE_CLEARING");
protocol: implement close as per BOLT #2. 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>
2016-03-24 02:39:41 +01:00
goto accept_clearing;
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
} else if (input_is_pkt(input)) {
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
peer_open_complete(peer, "unexpected packet");
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
goto unexpected_pkt;
}
break;
daemon: remove normal operation loop from state.c It's now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-06-28 23:19:20 +02:00
/* Should never happen. */
daemon: batching of changes as per BOLT #2. 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>
2016-03-31 08:43:20 +02:00
case STATE_NORMAL:
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
case STATE_NORMAL_COMMITTING:
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
case STATE_ERR_INTERNAL:
case STATE_ERR_ANCHOR_TIMEOUT:
daemon: handle information leak. As per onchain.md; log that an unknown spend occurred, and weep. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-06 04:26:32 +02:00
case STATE_ERR_INFORMATION_LEAK:
state: trim unused states. Now we never enter the state machine if we're dealing with on-chain transactions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-04 08:44:22 +02:00
case STATE_ERR_BREAKDOWN:
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
case STATE_CLOSED:
case STATE_MAX:
daemon: remove closing states from state machine. 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>
2016-05-26 07:55:24 +02:00
case STATE_CLEARING:
case STATE_CLEARING_COMMITTING:
case STATE_MUTUAL_CLOSING:
daemon: open-code handling of on-chain states. 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>
2016-05-04 08:44:22 +02:00
case STATE_CLOSE_ONCHAIN_CHEATED:
case STATE_CLOSE_ONCHAIN_THEIR_UNILATERAL:
case STATE_CLOSE_ONCHAIN_OUR_UNILATERAL:
case STATE_CLOSE_ONCHAIN_MUTUAL:
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
return next_state(peer, input, STATE_ERR_INTERNAL);
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
}
/* State machine should handle all possible states. */
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
return next_state(peer, input, STATE_ERR_INTERNAL);
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
unexpected_pkt:
daemon: remove normal operation loop from state.c It's now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-06-28 23:19:20 +02:00
peer_unexpected_pkt(peer, pkt);
state: use peer_unexpected_pkt() for an unexpected packet. Instead of effect->in_error. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:46 +01:00
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
/* Don't reply to an error with an error. */
state: trim unused states. Now we never enter the state machine if we're dealing with on-chain transactions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-04 08:44:22 +02:00
if (!input_is(input, PKT_ERROR)) {
goto breakdown;
state: fix case where we replied to an error with an error. Found by fixing bogus test in test_state_coverage.c Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-01-21 21:11:46 +01:00
}
daemon: remove normal operation loop from state.c It's now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-06-28 23:19:20 +02:00
err = pkt_err_unexpected(peer, pkt);
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
goto err_breakdown;
state: trim unused states. Now we never enter the state machine if we're dealing with on-chain transactions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-04 08:44:22 +02:00
err_breakdown:
state: queue packets directly. 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>
2016-03-30 08:27:18 +02:00
queue_pkt_err(peer, err);
state: trim unused states. Now we never enter the state machine if we're dealing with on-chain transactions. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-05-04 08:44:22 +02:00
breakdown:
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
return next_state(peer, input, STATE_ERR_BREAKDOWN);
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
protocol: implement close as per BOLT #2. 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>
2016-03-24 02:39:41 +01:00
accept_clearing:
daemon: remove normal operation loop from state.c It's now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-06-28 23:19:20 +02:00
err = accept_pkt_close_clearing(peer, pkt);
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
if (err)
daemon: always terminate waiting manual update command on failure. We missed some cases, resulting in hanging commands. Just check whenever we fail. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2016-06-28 23:19:20 +02:00
goto err_breakdown;
protocol: implement close as per BOLT #2. 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>
2016-03-24 02:39:41 +01:00
daemon: remove closing states from state machine. 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>
2016-05-26 07:55:24 +02:00
/* If we've sent commit, we're still waiting for it when clearing. */
if (peer->state == STATE_NORMAL_COMMITTING)
daemon: allow commands during commit. 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>
2016-05-26 07:55:25 +02:00
return next_state(peer, input, STATE_CLEARING_COMMITTING);
return next_state(peer, input, STATE_CLEARING);
state: Core state machine for lightning. It's written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-09-25 04:21:18 +02:00
}
Reference in New Issue Copy Permalink