Since bitcoind doesn't propagate non-main chains, there's little point
trying to be smart when we see them. This simplifies things immensely.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
It's primitive, but we re-broadcast any txs not included in the main
chain every time the tip moves. We only track transactions we are
watching, but that turns out to cover every transaction we generate
anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This can fail. Real cases include both sides dumping their commitment
txs in testing (only one can succeed).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We need to enforce this onchain as we do in the protocol off-chain,
otherwise we can have an onchain redemption we can't redeem upstream
via the protocol. While Laolu points out there's a 520 byte limit on
witness stack element, that can still make for a larger tx and make
problems for the steal tx case.
The downside is that even the timeout transaction, which used to spend
the HTLC with an empty 'secret', now needs a 32-byte secret, making it
a little larger. We create a 'bitcoin_witness_htlc' helper for this
case.
See: http://lists.linuxfoundation.org/pipermail/lightning-dev/2016-May/000529.html
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
They could be scriptpubkeys, but they're actually used inside p2wsh,
so they're really witness scripts. We use the term "redeem" elsewhere
from when we were using p2sh, though.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We watch the anchor output, and separate it into different cases.
This is simpler with segwit (txids are known before sigs), but we also
had missed the case of our own commit transaction spend.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
There's no reason to, it's a simple p2wpkh to our key.
We still spend the "to-us" from our commit tx, since it could be
theoretically be stolen by the revocation value, and it's a complex
p2wsh which a normal wallet won't have the information to spend.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Turns out that we want to pass information about the commit info, the
HTLC number and (sometimes) the R value, so create a struct for that.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
You can't re-enter the state machine from a callback, so this allows you
to queue an input for when it returns.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This turns out to make life easier for watching HTLC timeouts (we just
place a new watch for each HTLC).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
8a4246cb36 (permute: use BIP69 order) removed the invert_map change
from a25ba452f3 (permute_tx: fix horrible thinko.) but it's still
needed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since 43729c6856 (protocol: add output script to close_clearing message.)
the close scripts are not p2sh, but arbitrary. Fix the close tx matching.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Occasionally make seems to rebuild this in parallel, so make sure to
never have a partially complete one.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We just use a p2sh to a single address for the moment, but that's simply for
non-segwit wallets; we'll pay to whatever the other side specifies.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since any transaction with all segregated-witness inputs is non-malleable,
and all our transactions are that, we can remove normalized txids.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rather than p2sh of a 2of2, it's now a version 0 witness program.
This means that the commit transaction input and mutual close
transaction input are both different.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
BIP141 indicates that the rule for block size has changed: witness
bytes effectively count for 1, and non-witness bytes count for 4, but
the maximum total has increased to 4,000,000.
This means that fee estimates should use the witness cost (divided by
4), not the raw txlen.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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>
Rusty Russell