Rather than polling for interesting bitcoin txs via importaddress, we use
the chain topology to register our interest directly.x
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This allows us to track precise transaction depth ourselves,
particularly in the case of branching.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We need to control the *inputs* to the anchor tx, to make sure they
pay to witness scripts (thus the anchor is immalleable). The easiest
way to do this is to hand out P2SH addresses for the user, and have
them pay into those. Then they hand us that tx and we use it to
create the anchor.
This is not a long-term solution!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And divide fees as specified there.
We still use fixed values rather than floating, and we don't send or
handle update_fee messages.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We don't actually implement closing when we have HTLCs (we should
allow it, as that's what the clearing phase is for), since soon we'll
rewrite HTLC to match the async HTLC protocol of BOLT #2.
Note that this folds the close paths, using a simple check if we have
a close transaction. That's a slight state layer violation, but
reduces code duplication.
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>
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>
For better or worse, the ccan/timer structure is completely minimal,
and designed to be wrapped inside a container structure.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell