There isn't a single blockhash; we may be on multiple forks. But the one
caller which cares is commit_tx_depth(), which wants to know if the tx is
spendable yet. So that uses get_last_mediantime().
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We really want to do this for HTLCs; we don't do anything useful yet, but
this code replaces the direct call to bitcoind_watch_addr().
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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 gets the median time of the block the tx is in. If there is more
than one (different tips), it gets the last median time.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Like txids, we need to reverse them. We didn't, but then we only used them
to pass to/from bitcoind. We're about to get them from the block header,
so we need to fix that.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
With segregated witness, we can (in advance!) specify the txid or tx
output we want to watch, so convert to that now. For the moment it's
done by pretending we have normalized txids; that goes away after the
conversion.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This lets us live in a segwit world, before segwit. It's a shim which we
can remove once we've changed all our outputs.
We need a few more sleeps in our test script, since we've slowed
things down by doing these calls for every tx in every block.
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>
Otherwise, they're malleable. We only care about our own anchor:
their anchor is their problem (and they'll probably get away with it).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is an address that bitcoind will happily pay to, but we know it's
a witness output so our inputs to the anchor are immalleable.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
You need to be running a bitcoind modified with segregated witness:
https://github.com/sipa/bitcoin/tree/segwit4
It needs 432 blocks to activate it!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We currently linearize and then measure the string; this is better since
we're about to do it in a second place.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This can be used for proper support for fee negotiation; for the moment
it will be used for our anchor transaction creation.
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>
We need this for signing segwitness txs. Unfortunately, we don't have it
for transactions we received as hex, only ones we created; to make this safe
we use a pointer which is NULL if we don't know, and those will crash if
we try to sign or check their sigs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We got the -> second translation wrong by a factor of 512, and also we
need to move the median time in our tests otherwise bitcoind won't let
us spend the tx.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I had already disabled it, and this clears the decks for Segregated Witness
which gives us everything we want.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We always set *matches to false (outside the branch, oops). We also
distinguish the case where we ack from the case where they acked,
which removes a FIXME and makes it work.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We now keep a list of commitment transaction states for "us" and
"them", as well as a "struct channel_state" for staged changes.
We manipulate these structures as we send out packets, receive
packets, or receive acknowledgement of packets. In particular, we
update the other nodes' staging_cstate as we send out our requests,
and update our own staging_cstate are we receive acks. When we
receive a request, we update both (as we immediately send out our
ack).
The RPC output is changed; rather than expose the complexity, we
expose our last committed state: what would happen if we have to drop
to the blockchain now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rather than creating packets then queueing them, call out to functions
which do both. This moves us towards doing more work in those functions
where we send out a request, which is sometimes clearer.
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 used to have a hacky close timeout which would immediately fire
when we'd closed because the connection was down. Far better to have
a specific "connection lost" input, and have it respond like CMD_CLOSE.
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>
For the change to asynchronous updates as specified by BOLT #2, we
need to know when the other side acknowledged a packet. This creates
a simple callback mechanism for it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This uses libsodium (we could use openssl, but the required primitives
are only in 1.1.0 which is still in alpha).
It doesn't handle reconnections yet, either.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell
zhibiao.pan