We used to have a hacky close timeout which would immediately fire
when we'd closed because the connection was down. Far better to have
a specific "connection lost" input, and have it respond like CMD_CLOSE.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't actually implement closing when we have HTLCs (we should
allow it, as that's what the clearing phase is for), since soon we'll
rewrite HTLC to match the async HTLC protocol of BOLT #2.
Note that this folds the close paths, using a simple check if we have
a close transaction. That's a slight state layer violation, but
reduces code duplication.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
This tell us to disarm the INPUT_CLOSE_COMPLETE_TIMEOUT: either we hit
an error and are going to unilateral close, or we received their signature
successfully.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Actually generating the anchor transaction in my implementation
requires interaction with bitcoind, which we want to be async. So add
a callback and a new state to wait for it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We use both union fields idata->btc and idata->htlc, which is clearly
wrong. Have peer_tx_revealed_r_value return the HTLC it's talking
about.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This lets us eliminate struct state_effect altogether (the next patch
removes the now-unused arguments).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We only have one htlc in flight at a time, but sometimes it changes:
particularly when we are lowpriority and a highpriority request comes
in. Handle this using a set of callbacks for htlc handling.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Now we're covered by the opening command anyway, and the rule that you
can't have two commands at once.
There are two more defers:
1) In state STATE_WAIT_FOR_UPDATE_SIG_LOWPRIO/HIGHPRIO we are waiting for
their signature because they started an HTLC, we defer any new HTLC
creation, and
2) We defer PKT_OPEN_COMPLETE when we're waiting for anchor depth.
The first can be solved by a flag indicating whether we are accepting new
commands at all, the second by a pair of new states.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is conceptually cleaner, especially since it means we're running
a command until we're set up (which prevents other commands, so no
special case needed).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Reveals a number of places where we don't handle errors correctly.
Note: this takes about 14.5 GB to test on my x86-64 box.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We'd expect stop_commands to stop all commands, but we (ab)used
CMD_SEND_HTLC_FULFILL to send us R values even in closing state.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When a unilateral close occurs, we have to watch on-chain ("live")
HTLCs. If the other side spends their HTLC output, we need to grab
the rvalue. If it times out, we need to spend it back to ourselves.
If we get an R value, we need to spend our own HTLC output back to
ourselves.
Because there are multiple HTLCs, this doesn't fit very neatly into a
state machine. We divide into "have htlcs" and "don't have htlcs",
and use a INPUT_NO_MORE_HTLCS once all htlcs are resolved to transition.
Our test harness now tracks individual HTLCs, so we refined some
inputs (in particular, it won't try to complete/timeout an HTLC before
we have any).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell