The latest version of the BIP doesn't use inversion, but does use
bitshifts.
It also uncovered a bug in the test scripts: the block timestamps
creep forward when we generate large numbers of blocks (UpdateTime
insists it be > GetMedianTimePast() so it's valid). We need to take
this into account when waiting for the median to move (reduced it from
60 to 30 seconds, since that adds about 14 seconds).
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>
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>
Rusty Russell