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>
switched from pyelliptic to hmac/binascii/cryptography for standard
functions
use our own ECDH implementation to better match the one from secp256k1
finally, add function to create an encrypted onion
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>
