Actually generating the anchor transaction in my implementation
requires interaction with bitcoind, which we want to be async. So add
a callback and a new state to wait for it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We use both union fields idata->btc and idata->htlc, which is clearly
wrong. Have peer_tx_revealed_r_value return the HTLC it's talking
about.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This lets us eliminate struct state_effect altogether (the next patch
removes the now-unused arguments).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We only have one htlc in flight at a time, but sometimes it changes:
particularly when we are lowpriority and a highpriority request comes
in. Handle this using a set of callbacks for htlc handling.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When a unilateral close occurs, we have to watch on-chain ("live")
HTLCs. If the other side spends their HTLC output, we need to grab
the rvalue. If it times out, we need to spend it back to ourselves.
If we get an R value, we need to spend our own HTLC output back to
ourselves.
Because there are multiple HTLCs, this doesn't fit very neatly into a
state machine. We divide into "have htlcs" and "don't have htlcs",
and use a INPUT_NO_MORE_HTLCS once all htlcs are resolved to transition.
Our test harness now tracks individual HTLCs, so we refined some
inputs (in particular, it won't try to complete/timeout an HTLC before
we have any).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell