lukechilds
/
lightning
mirror of https://github.com/lukechilds/lightning.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
663 Commits
55 Branches
107 Tags
38 MiB
Tree: 1444d407f3
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '1444d407f3'
${ noResults }
lightning/state.c

278 lines
8.4 KiB
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>
9 years ago
#include <ccan/build_assert/build_assert.h>
daemon: log all state changes the same way. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
#include <daemon/log.h>
state: include daemon/peer (only if !TEST_COVERAGE). Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
#ifndef TEST_STATE_COVERAGE
#include <daemon/peer.h>
#endif
daemon: log all state changes the same way. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
#include <names.h>
state: order headers correctly. make check-source will complain once we include state.c. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
#include <state.h>
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
static enum state next_state(struct peer *peer,
const enum state_input input,
const enum state state)
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
{
state: set peer-&gt;state directly. Instead of new_state effect. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
assert(peer->state != state);
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
return state;
state: set peer-&gt;state directly. Instead of new_state effect. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
}
state: make tx arguments const. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
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-&gt;broadcast_tx. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
{
assert(!*broadcast);
assert(tx);
*broadcast = tx;
}
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
enum state state(struct peer *peer,
const enum state_input input,
daemon: remove normal operation loop from state.c It&#39;s now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
const Pkt *pkt,
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
const struct bitcoin_tx **broadcast)
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
{
Pkt *err;
state: return status of current command. We temporarily move effect to the end of the arg list: we&#39;ll get rid of it eventually. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
state: return tx to be queued directly. Instead of effect-&gt;broadcast_tx. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
*broadcast = NULL;
state: return Pkt to be queued directly. Instead of effect-&gt;send_pkt. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
state: set peer-&gt;state directly. Instead of new_state effect. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
switch (peer->state) {
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
/*
* Initial channel opening states.
*/
state: use STATE_INIT and separate inputs to decide on anchor. This is conceptually cleaner, especially since it means we&#39;re running a command until we&#39;re set up (which prevents other commands, so no special case needed). Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
case STATE_INIT:
if (input_is(input, CMD_OPEN_WITH_ANCHOR)) {
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
queue_pkt_open(peer,
OPEN_CHANNEL__ANCHOR_OFFER__WILL_CREATE_ANCHOR);
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
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&#39;re running a command until we&#39;re set up (which prevents other commands, so no special case needed). Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
STATE_OPEN_WAIT_FOR_OPEN_WITHANCHOR);
} else if (input_is(input, CMD_OPEN_WITHOUT_ANCHOR)) {
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
queue_pkt_open(peer,
OPEN_CHANNEL__ANCHOR_OFFER__WONT_CREATE_ANCHOR);
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
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&#39;re running a command until we&#39;re set up (which prevents other commands, so no special case needed). Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
STATE_OPEN_WAIT_FOR_OPEN_NOANCHOR);
}
break;
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
case STATE_OPEN_WAIT_FOR_OPEN_NOANCHOR:
if (input_is(input, PKT_OPEN)) {
daemon: remove normal operation loop from state.c It&#39;s now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
err = accept_pkt_open(peer, pkt);
state: use STATE_INIT and separate inputs to decide on anchor. This is conceptually cleaner, especially since it means we&#39;re running a command until we&#39;re set up (which prevents other commands, so no special case needed). Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
if (err) {
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_open_complete(peer, err->error->problem);
state: trim unused states. Now we never enter the state machine if we&#39;re dealing with on-chain transactions. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
goto err_breakdown;
state: use STATE_INIT and separate inputs to decide on anchor. This is conceptually cleaner, especially since it means we&#39;re running a command until we&#39;re set up (which prevents other commands, so no special case needed). Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
}
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
return next_state(peer, input, STATE_OPEN_WAIT_FOR_ANCHOR);
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
} else if (input_is_pkt(input)) {
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_open_complete(peer, "unexpected packet");
state: trim unused states. Now we never enter the state machine if we&#39;re dealing with on-chain transactions. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
goto unexpected_pkt;
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
}
break;
case STATE_OPEN_WAIT_FOR_OPEN_WITHANCHOR:
if (input_is(input, PKT_OPEN)) {
daemon: remove normal operation loop from state.c It&#39;s now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
err = accept_pkt_open(peer, pkt);
state: use STATE_INIT and separate inputs to decide on anchor. This is conceptually cleaner, especially since it means we&#39;re running a command until we&#39;re set up (which prevents other commands, so no special case needed). Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
if (err) {
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_open_complete(peer, err->error->problem);
state: trim unused states. Now we never enter the state machine if we&#39;re dealing with on-chain transactions. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
goto err_breakdown;
state: use STATE_INIT and separate inputs to decide on anchor. This is conceptually cleaner, especially since it means we&#39;re running a command until we&#39;re set up (which prevents other commands, so no special case needed). Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
}
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
bitcoin_create_anchor(peer, BITCOIN_ANCHOR_CREATED);
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
STATE_OPEN_WAIT_FOR_ANCHOR_CREATE);
} else if (input_is_pkt(input)) {
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_open_complete(peer, "unexpected packet");
state: trim unused states. Now we never enter the state machine if we&#39;re dealing with on-chain transactions. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
}
break;
case STATE_OPEN_WAIT_FOR_ANCHOR_CREATE:
if (input_is(input, BITCOIN_ANCHOR_CREATED)) {
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
queue_pkt_anchor(peer);
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
STATE_OPEN_WAIT_FOR_COMMIT_SIG);
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
} 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
bitcoin_release_anchor(peer, BITCOIN_ANCHOR_CREATED);
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_open_complete(peer, "unexpected packet");
state: trim unused states. Now we never enter the state machine if we&#39;re dealing with on-chain transactions. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
goto unexpected_pkt;
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
}
break;
case STATE_OPEN_WAIT_FOR_ANCHOR:
if (input_is(input, PKT_OPEN_ANCHOR)) {
daemon: remove normal operation loop from state.c It&#39;s now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
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&#39;re running a command until we&#39;re set up (which prevents other commands, so no special case needed). Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
if (err) {
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_open_complete(peer, err->error->problem);
state: trim unused states. Now we never enter the state machine if we&#39;re dealing with on-chain transactions. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
goto err_breakdown;
state: use STATE_INIT and separate inputs to decide on anchor. This is conceptually cleaner, especially since it means we&#39;re running a command until we&#39;re set up (which prevents other commands, so no special case needed). Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
}
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
queue_pkt_open_commit_sig(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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_watch_anchor(peer,
BITCOIN_ANCHOR_DEPTHOK,
state: trim unused states. Now we never enter the state machine if we&#39;re dealing with on-chain transactions. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
BITCOIN_ANCHOR_TIMEOUT);
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
STATE_OPEN_WAITING_THEIRANCHOR);
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
} else if (input_is_pkt(input)) {
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_open_complete(peer, "unexpected packet");
state: trim unused states. Now we never enter the state machine if we&#39;re dealing with on-chain transactions. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
goto unexpected_pkt;
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
}
break;
case STATE_OPEN_WAIT_FOR_COMMIT_SIG:
if (input_is(input, PKT_OPEN_COMMIT_SIG)) {
daemon: remove normal operation loop from state.c It&#39;s now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
err = accept_pkt_open_commit_sig(peer, pkt);
state: use STATE_INIT and separate inputs to decide on anchor. This is conceptually cleaner, especially since it means we&#39;re running a command until we&#39;re set up (which prevents other commands, so no special case needed). Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
bitcoin_release_anchor(peer, INPUT_NONE);
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_open_complete(peer, err->error->problem);
state: trim unused states. Now we never enter the state machine if we&#39;re dealing with on-chain transactions. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
goto err_breakdown;
state: use STATE_INIT and separate inputs to decide on anchor. This is conceptually cleaner, especially since it means we&#39;re running a command until we&#39;re set up (which prevents other commands, so no special case needed). Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
}
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_watch_anchor(peer,
BITCOIN_ANCHOR_DEPTHOK,
state: trim unused states. Now we never enter the state machine if we&#39;re dealing with on-chain transactions. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
INPUT_NONE);
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
return next_state(peer, input,
state: return status of current command. We temporarily move effect to the end of the arg list: we&#39;ll get rid of it eventually. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
STATE_OPEN_WAITING_OURANCHOR);
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
} 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
bitcoin_release_anchor(peer, INPUT_NONE);
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_open_complete(peer, "unexpected packet");
state: trim unused states. Now we never enter the state machine if we&#39;re dealing with on-chain transactions. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
goto unexpected_pkt;
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
}
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
if (input_is(input, PKT_OPEN_COMPLETE)) {
daemon: remove normal operation loop from state.c It&#39;s now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
if (err) {
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_open_complete(peer, err->error->problem);
state: explicit callback to check pkt_open_complete. For now, this always succeeds, but include the hook for completeness. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
/* We no longer care about anchor depth. */
peer_unwatch_anchor_depth(peer,
BITCOIN_ANCHOR_DEPTHOK,
INPUT_NONE);
state: trim unused states. Now we never enter the state machine if we&#39;re dealing with on-chain transactions. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
}
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
STATE_OPEN_WAITING_OURANCHOR_THEYCOMPLETED);
}
/* Fall thru */
case STATE_OPEN_WAITING_OURANCHOR_THEYCOMPLETED:
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
queue_pkt_open_complete(peer);
state: set peer-&gt;state directly. Instead of new_state effect. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
if (peer->state == STATE_OPEN_WAITING_OURANCHOR_THEYCOMPLETED) {
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
}
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
STATE_OPEN_WAIT_FOR_COMPLETE_OURANCHOR);
protocol: implement close as per BOLT #2. We don&#39;t actually implement closing when we have HTLCs (we should allow it, as that&#39;s what the clearing phase is for), since soon we&#39;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&#39;s a slight state layer violation, but reduces code duplication. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
} else if (input_is(input, PKT_CLOSE_CLEARING)) {
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
/* We no longer care about anchor depth. */
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_unwatch_anchor_depth(peer,
BITCOIN_ANCHOR_DEPTHOK,
INPUT_NONE);
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_open_complete(peer, "Received PKT_CLOSE_CLEARING");
protocol: implement close as per BOLT #2. We don&#39;t actually implement closing when we have HTLCs (we should allow it, as that&#39;s what the clearing phase is for), since soon we&#39;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&#39;s a slight state layer violation, but reduces code duplication. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
goto accept_clearing;
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
} else if (input_is_pkt(input)) {
/* We no longer care about anchor depth. */
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_unwatch_anchor_depth(peer,
BITCOIN_ANCHOR_DEPTHOK,
INPUT_NONE);
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_open_complete(peer, "unexpected packet");
state: cleanup after anchor has been transmitted. If something goes wrong after we&#39;ve broadcast the anchor tx, we need to use the commit tx to spend it. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
goto unexpected_pkt;
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
}
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
if (input_is(input, PKT_OPEN_COMPLETE)) {
daemon: remove normal operation loop from state.c It&#39;s now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
if (err) {
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_open_complete(peer, err->error->problem);
state: explicit callback to check pkt_open_complete. For now, this always succeeds, but include the hook for completeness. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
/* We no longer care about anchor depth. */
peer_unwatch_anchor_depth(peer,
BITCOIN_ANCHOR_DEPTHOK,
BITCOIN_ANCHOR_TIMEOUT);
state: trim unused states. Now we never enter the state machine if we&#39;re dealing with on-chain transactions. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
}
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
STATE_OPEN_WAITING_THEIRANCHOR_THEYCOMPLETED);
}
/* Fall thru */
case STATE_OPEN_WAITING_THEIRANCHOR_THEYCOMPLETED:
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
queue_pkt_err(peer, pkt_err(peer, "Anchor timed out"));
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
return next_state(peer, input, STATE_ERR_ANCHOR_TIMEOUT);
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
} 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
queue_pkt_open_complete(peer);
state: set peer-&gt;state directly. Instead of new_state effect. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
if (peer->state == STATE_OPEN_WAITING_THEIRANCHOR_THEYCOMPLETED) {
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
}
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
return next_state(peer, input,
state: return status of current command. We temporarily move effect to the end of the arg list: we&#39;ll get rid of it eventually. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
STATE_OPEN_WAIT_FOR_COMPLETE_THEIRANCHOR);
protocol: implement close as per BOLT #2. We don&#39;t actually implement closing when we have HTLCs (we should allow it, as that&#39;s what the clearing phase is for), since soon we&#39;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&#39;s a slight state layer violation, but reduces code duplication. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
} else if (input_is(input, PKT_CLOSE_CLEARING)) {
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
/* We no longer care about anchor depth. */
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_unwatch_anchor_depth(peer,
BITCOIN_ANCHOR_DEPTHOK,
BITCOIN_ANCHOR_TIMEOUT);
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_open_complete(peer, "Received PKT_CLOSE_CLEARING");
protocol: implement close as per BOLT #2. We don&#39;t actually implement closing when we have HTLCs (we should allow it, as that&#39;s what the clearing phase is for), since soon we&#39;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&#39;s a slight state layer violation, but reduces code duplication. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
goto accept_clearing;
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
} else if (input_is_pkt(input)) {
/* We no longer care about anchor depth. */
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_unwatch_anchor_depth(peer,
BITCOIN_ANCHOR_DEPTHOK,
BITCOIN_ANCHOR_TIMEOUT);
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_open_complete(peer, "unexpected packet");
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
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&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
/* Ready for business! */
peer_open_complete(peer, NULL);
return next_state(peer, input, STATE_NORMAL);
protocol: implement close as per BOLT #2. We don&#39;t actually implement closing when we have HTLCs (we should allow it, as that&#39;s what the clearing phase is for), since soon we&#39;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&#39;s a slight state layer violation, but reduces code duplication. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
} else if (input_is(input, PKT_CLOSE_CLEARING)) {
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_open_complete(peer, "Received PKT_CLOSE_CLEARING");
protocol: implement close as per BOLT #2. We don&#39;t actually implement closing when we have HTLCs (we should allow it, as that&#39;s what the clearing phase is for), since soon we&#39;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&#39;s a slight state layer violation, but reduces code duplication. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
goto accept_clearing;
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
} else if (input_is_pkt(input)) {
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_open_complete(peer, "unexpected packet");
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
goto unexpected_pkt;
}
break;
daemon: remove normal operation loop from state.c It&#39;s now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
/* Should never happen. */
daemon: batching of changes as per BOLT #2. We now keep a list of commitment transaction states for &#34;us&#34; and &#34;them&#34;, as well as a &#34;struct channel_state&#34; 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&#39; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
case STATE_NORMAL:
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
case STATE_NORMAL_COMMITTING:
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
case STATE_ERR_INFORMATION_LEAK:
state: trim unused states. Now we never enter the state machine if we&#39;re dealing with on-chain transactions. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
case STATE_ERR_BREAKDOWN:
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
case STATE_CLOSED:
case STATE_MAX:
daemon: remove closing states from state machine. We already removed the on-chain states, now we remove the &#34;clearing&#34; state (which wasn&#39;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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
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&#39;re done when they&#39;re irrevocable. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
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&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
return next_state(peer, input, STATE_ERR_INTERNAL);
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
}
/* State machine should handle all possible states. */
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
return next_state(peer, input, STATE_ERR_INTERNAL);
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
unexpected_pkt:
daemon: remove normal operation loop from state.c It&#39;s now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
peer_unexpected_pkt(peer, pkt);
state: use peer_unexpected_pkt() for an unexpected packet. Instead of effect-&gt;in_error. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
/* Don't reply to an error with an error. */
state: trim unused states. Now we never enter the state machine if we&#39;re dealing with on-chain transactions. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
}
daemon: remove normal operation loop from state.c It&#39;s now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
err = pkt_err_unexpected(peer, pkt);
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
goto err_breakdown;
err_breakdown_maybe_committing:
if (peer->state == STATE_NORMAL_COMMITTING)
peer_update_complete(peer, "bad packet");
state: trim unused states. Now we never enter the state machine if we&#39;re dealing with on-chain transactions. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
queue_pkt_err(peer, err);
state: trim unused states. Now we never enter the state machine if we&#39;re dealing with on-chain transactions. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
breakdown:
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
return next_state(peer, input, STATE_ERR_BREAKDOWN);
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
protocol: implement close as per BOLT #2. We don&#39;t actually implement closing when we have HTLCs (we should allow it, as that&#39;s what the clearing phase is for), since soon we&#39;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&#39;s a slight state layer violation, but reduces code duplication. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
accept_clearing:
daemon: remove normal operation loop from state.c It&#39;s now in its own little state machine, which is more typesafe. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
err = accept_pkt_close_clearing(peer, pkt);
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
if (err)
daemon: allow commands during commit. There&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
goto err_breakdown_maybe_committing;
protocol: implement close as per BOLT #2. We don&#39;t actually implement closing when we have HTLCs (we should allow it, as that&#39;s what the clearing phase is for), since soon we&#39;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&#39;s a slight state layer violation, but reduces code duplication. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
daemon: remove closing states from state machine. We already removed the on-chain states, now we remove the &#34;clearing&#34; state (which wasn&#39;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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
/* 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&#39;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&#39;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 &#34;peercond&#34; 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 &lt;rusty@rustcorp.com.au&gt;
9 years ago
return next_state(peer, input, STATE_CLEARING_COMMITTING);
return next_state(peer, input, STATE_CLEARING);
state: Core state machine for lightning. It&#39;s written in a repetitive and stylized form, for easier testing. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
9 years ago
}