Rather than generating it after as we return failure. This makes
it easier to save it for the next patch where we want to report failure.
Also put num_peer_outputs in there, so we don't have to access
after->peer on reporting.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Otherwise hashing might not spot duplicate states. Doesn't seem to
make much difference in timing in practice though.
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>
By terminating in either NORMAL state, we halve the time to run the
coverage test.
Before:
real 0m50.083s
After:
real 0m28.548s
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Once both are longer listening to their packets, we don't need to
simulate all variants of what each are doing.
(With -O3 -flto, gcc 5.1)
Before:
real 11m40.032s
After:
real 0m50.083s
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For loop detection, we don't need entire state. So extract a core,
which we can put in hash table.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This requires our state exerciser to be smarter. In particular, it
needs to track individual HTLCs rather than just sending random
inputs.
To do this:
1) We keep data associated with packets as they flow (where
those packets are associated with HTLCs).
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>
These tests are wrong, and are handled properly anyway when they
fire (the other one is disabled).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We should always have a packet in flight unless we're in the two
waiting-for-anchor-to-mature states, or at the top of the main loop.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The state machine is infinite, but if we eliminate the normal inner
state loop, and a couple of other unusual cases where inputs can
repeat, we should be able to traverse it all.
This is slower than simply stopping when we hit a repeated state
though.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For the moment, there's no way to remove an in-progress HTLC before
it's timed out. The other side can remove it with a routefail, but
you can't push for it to be removed.
We may add that later, but by definition it's only a polited request, and
normally we should rely on timeouts.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't have to accept an HTLC they offer; we might not be able to
route it, or it might offer insufficient payment.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This gets truncated for on-chain transactions (thus, rounding may
contribute to fees).
This also means we currently have an upper bound of 0.04 BTC per HTLC;
this can be increased later if required.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
