It fits in a u32, but we mix it with other values which could cause
overflow, so let's just use u64 everywhere.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is dumb, since one side will never succeed. But in future when
there is a method for nodes to broadcast their public address (or send
their address inline to connected nodes), either side should try to
connect.
Importantly though, there are places which will queue packets at
various times (eg. HTLC timeout), so we need to clear the queue just
before re-transmitting, not when disconnecting.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
To do this we keep an order counter so we know how to retransmit. We
could simply keep old packets, but this is a little clearer for now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Caught because we generated an HTLCs which had already expired, since
we didn't know the latest block. Other errors are certainly possible,
so it's safest to load the entire thing before going live.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This avoids us having to query it when we create anchor transaction, and
lets us always use dynamic fee information.
The config options for max and min are now percentages, rather than absolute.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We no longer need it anywhere. This simplifies things to the point where
we might as well just not include dust outputs as we go, rather than
explicitly removing them, which gets rid of remove_dust.c as well.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Similar to the way we derive which outputs are which for old transactions
we steal, we derive them even for their current transaction.
We keep track of this information in peer->closing.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
At the moment, for our or their unilateral close, we create a resolved[]
entry for our output, their output, and each HTLC, in cstate order. Some
of these outputs might not exist (too small), so it's actually better
to simply keep a resolved[] entry for each of the tx's actual outputs.
(We already changed the steal resolved[] array to work like this, but
these are trickier, since we rely on that order if we need to fulfill an
on-chain HTLC).
It also helps as we are weaning off knowing the cstate and permutation
mapping for each commitment transaction.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We want to stop keeping old commitment information (except the minimal
txid to commitment-number mapping). One place we currently use it is
after sending a commitment signature, and before we've received the
revocation for the old commitment. For this duration, there are two
valid commitment transactions.
So we store "their_prev_revocation_hash" explicitly for this duration.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's a data-leak to send ack before we have verified identity of peer.
Plus, we can't send it until we know which peer it is, anyway!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And use this to resolve old transactions by comparing outputs with
HTLCs.
Rather than remembering the output ordering for every one of their
previous commitment transactions, we just remember the commitment
number for each commitment txid, and when we see it, derive all the
HTLC scriptpubkeys and the to-us and to-them scriptpubkeys, and figure
out which is which.
This avoids us having to save information on disk, except for the
txid->commitment-number mapping (and the shachain).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This makes it explicit, which is better for storing in a database (before
it was just what watch callback, plus peer->local.mindepth).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Move other logic into caller, but it's not complete (it still needs to
check some things, and still records some results).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Move other logic into caller: it grew this way because we used to have
a centralized "state" machine which knew nothing of these internal
details. But now we want to re-queue packets on reconnect, we really
want these routines to be idempotent.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We're weaning off the cstate arrays; use the htlc map. But for the
moment we keep the output basically the same.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We had an occasional race where we hadn't gotten the remote revocation
before submitting fulfill (spotted by the HTLC state transition code).
Disallow this, but also add to the json output so we can wait for
an HTLC to be irrevocably committed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If we always remove " from JSON, our parsing becomes simpler; turns
out that we did that in some places, and check()'s eval removed them
from the comparison.
We extract check_balance_single() to check the general balance, then
grep for HTLCs separately.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Not separate "locally-offered" and "remotely-offered" ones; we can
distinguish them by htlc->state now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since we only care about the latest commits, we can simply associate a
state with each HTLC, rather than using queues of HTLCs associated
with each commitment transaction.
This works far better in the context of a database.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We keep a "database" for each side's persistent state. Upon restart,
each side tells the other where it was up to, in terms of the number
of commit and revocation messages it receives.
Because only one update can be in flight at a time, we can tell w
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is simpler for database representation, and also allows simple
bit-tests for what is happening to a HTLC (eg. am I committed to it?
Are you? etc.)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Laolu pointed out that we can't have multiple in flight, since we can't
sign without knowing the next revocation preimage.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
