This is only for the simple case where there are no HTLCs.
We group the current commit information together in the struct;
this involves a trivial transform from peer->cur_commit_theirsig to
peer->cur_commit.theirsig.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is required for transactions which use OP_CSV to lock outputs for
a given amount of time: we need to know the mediantime of the block
they were included into.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We abort when this happens, but still worth testing.
This involves a refactor so we can allocate watches off a specific context,
for easy freeing when they're no longer wanted.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When a peer is finally to be freed (ie. STATE_CLOSED), doing this
inside the state logic is a bit fraught. We're better off exiting the
io loop and freeing it there.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We do the simplest thing: a timer goes off, and we check all HTLCs for
one which has expired more than 30 seconds ago.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Otherwise we won't finish the conversation. In fact, only the writer
side should ever close: we wake it if we want to close and it tests
peer->cond.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
When the only commands are via JSON, you might argue that we should
simply insist the user not operate on the same peer in parallel. That
would suck, and also we need to handle the case of a command from
a timer (eg. HTLC expiry!) or a bitcoin event.
So, we need a queue for commands, but also we need to do some of the
command checking just before the command runs: the HTLC we're dealing
with might have vanished for example.
The current command is wrapped in an anonymous "curr_cmd" struct
for extra clarity.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This lets us implement accept_pkt_anchor().
Also had to predeclare sha256 in commit_tx.h, revealed by the new
includes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
bitcoind has a limit of 16 requests at once, by default, so our simplest
solution is to serialize them.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Because we use the bitcoin wallet to create the anchor transaction, we
need to make sure it doesn't broadcast it; safest to check their config
for the option.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It was "connecting" to "localhost 30000" successfully, because it was
using UDP. Oops.
This reveals another issue: init_conn() uses the wrong address to
connect to, as we'd already incremented the pointer in try_connect_one().
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell