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>
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>
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>
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>
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>
