Rather than keeping each hop, we can generate it in place since we only
need the first hop result.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means we can save the partial HMAC of the padding for each step,
rather than the padding itself, when generating it.
Each step now takes the *last*, not *first* part of the onion array.
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>
Not much help yet, but vital when we increase the number of fail points.
Before:
Maximum resident set size (kbytes): 1080148
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 271614
Voluntary context switches: 1
Involuntary context switches: 1083
After:
Maximum resident set size (kbytes): 1062344
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 266236
Voluntary context switches: 1
Involuntary context switches: 2509
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
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>
