This is a bit tricky: for our signing code, we don't want scriptsigs,
but to calculate the txid, we need them. For most transactions in lightning,
they're pure segwit so it doesn't matter, but funding transactions can
have P2SH-wrapped P2WPKH inputs.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a step away from the previous more generic script types into
specific helpers for each transaction type we need.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We had a hack for 'struct rval' in protobuf_convert.h; make an
explicit header and put it in bitcoin/preimage.h. It's not really
bitcoin-specific, but it's better than having bitcoin/script depend on
an external header.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Encodings are signed: we may need 5 bytes to encode giant u32s.
Reported-by: Fabrice Drouin <fabrice.drouin@acinq.fr>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
The object file should not be built inside the submodule, as that can
confuse git.
Not everything depends on the libbase58 header (CCAN doesn't), so
move that to the everything-else depends line.
The BITCOIN_SRC etc should also move to bitcoin/Makefile, but that's
a bigger change.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Added channel announcement serialization and parsing, as well as the
entrypoints for the IRC peer discovery. Announcements are signed by the
sending endpoint and signatures are verified before adding the channels
to the local view of the topology. We do not yet verify the existence of
the anchor transaction.
1. Fix #ifdef DEBUG code in signature.c so it compiles.
2. Don't set peer->closing.our_script in queue_pkt_close_shutdown: it's
assigned in caller already.
3. Wrap setting of htlc's rval in set_htlc_rval() function.
4. Log where we were when unexpected packet comes in.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And use this to resolve old transactions by comparing outputs with
HTLCs.
Rather than remembering the output ordering for every one of their
previous commitment transactions, we just remember the commitment
number for each commitment txid, and when we see it, derive all the
HTLC scriptpubkeys and the to-us and to-them scriptpubkeys, and figure
out which is which.
This avoids us having to save information on disk, except for the
txid->commitment-number mapping (and the shachain).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
From doing a code walkthrough with Christian Decker; unnecessary const in
bitcoin/tx.c, an erroneous FIXME, a missing comment, and an unused struct.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Update libsecp256k1 has a normalize function, which allows us to test
if the signature was in low-S form.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We use libsecp256k1 to convert signatures to DER; we were creating a
temporary one, but we really should be handing the one we have in dstate
through. This does that, everywhere.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We now need to use bitcoin_witness_htlc with the r value, so that API
is updated to take 'struct rval' or 'struct sha256'.
We use the nc->delay amount (ie. dstate->config.min_htlc_expiry) to
wait for a timeout refund to be buried before "failing" upstream.
This should probably be made into a clearer parameter rather than
overloading this one.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Header from folded patch 'dont-use-peer-nc-in-onchain-code.patch':
peer: Don't use peer->nc->delay for onchain case.
Use the config var directly. We should be freeing peer->nc when the
connection dies anyway.
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>
Rusty Russell
Christian Decker
Lucas Betschart
Jacob