Re-enabling the next test revealed bugs: if we need to retransmit the
initial open_commit_sig packet, we currently tried to send it as an
UPDATE_COMMIT, which isn't allowed. Fixing that revealed that if
we have to retransmit the initial open, we didn't do that either.
Thus the initial open should count towards the ack count, and we should
special case transmissions of 0 (pkt_open) and 1
(pkt_open_commit_sig).
We also save those early state changes to the database.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since we no longer feed it into state.c, we can just us a bool.
And that's the last of the CMD_* in the enum state_input, so remove them
all.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We can get weird errors when we try to load a database of a different
from. Just slap a git version in there for now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Running on my build machine, without valgrind, it managed to exchange
closing sigs before restart, and spotted this bug.
Fixes: #76
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Firstly, we need to update the staging fee amount when we queue a change.
Secondly we need to remove completed fee updates, otherwise we hit a
database constraint that peer & state are unique.
Reported-by: Christian Decker
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's not in a transaction in one caller, so wrap that.
This removes some more error handling code.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We need some ordering to deliver them to the JSON "waitinvoice" command;
we use a counter where 0 means "unpaid".
We keep two lists now, one for unpaid and one for paid invoices.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I had some nonsensical columns, eg "bool ours", but sqlite3 pretty much
ignores them. Use macros so mistakes are harder to make.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is important when we put payments in the database: they need to be
updated atomically as the HTLC is.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is important when we put payments in the database: they need to be
updated atomically as the HTLC is.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We had enum channel_side (OURS, THEIRS) for which end of a channel we
had, and htlc_side (LOCAL, REMOTE) for who proposed the HTLC.
Combine these both into simply "enum side".
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We create a logging object when we connect, then carry it through. If
it comes from the database, we just use the peerid as the log prefix.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's not currently encrypted, but at least you get some idea now why
an HTLC failed. We (ab)use HTTP error codes for the moment.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't have an ordering of HTLCs between peers: we don't know
whether your HTLC 0 or my HTLC 0 occurred first. This matters,
as we play them all back to reconstruct state (probably overkill anyway).
So we add force_* operators which don't do bounds checks, and do
bounds checks at the end. We also note that we don't need to apply
fee changes: that should be in the database already.
Also relax db constraints: IDs are not unique, they are unique per
side (we can both have HTLC #0).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I originally overloaded struct htlc for this, as they go through the
same states, but separating them turned out to be clearer.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This makes more sense eventually: we may know the network addresses of
many peers, not just those we're connecting to. So keep a mapping, and
update it when we successfully connect outwards.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell