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>
Rusty Russell
pm47