Originally we were supposed to tell the HSM we had just created the directory,
otherwise it wouldn't create a new seed. But we modified it to check if
there was a seed file anyway: just move that logic into a branch of hsmd.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In particular, the main daemon and subdaemons share the backtrace code,
with hooks for logging.
The daemon hook inserts the io_poll override, which means we no longer
need io_debug.[ch]. Though most daemons don't need it, they still link
against ccan/io, so it's harmess (suggested by @ZmnSCPxj).
This was tested manually to make sure we get backtraces still.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If we're going to simply take() a pointer, don't allocate it off a random
object. Using NULL makes our intent clear, particularly with allocating
packets we're going to take() onto a queue.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We always hand in "NULL" (which means use tal_len on the msg), except
for two places which do that manually for no good reason.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
These are now logically arrays of pointers. This is much more natural,
and gets rid of the horrible utxo array converters.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We log at a higher level when we have problems, and also just fail if
master behaves, rather than complaining and hanging.
Closes: #335
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
All other users of derive_simple_privkey(...) check the return value:
```
channeld/channel.c: if (!derive_simple_privkey(&peer->our_secrets.htlc_basepoint_secret,
lightningd/test/run-commit_tx.c: if (!derive_simple_privkey(&x_remote_htlc_basepoint_secret,
lightningd/test/run-commit_tx.c: if (!derive_simple_privkey(&x_local_delayed_payment_basepoint_secret,
lightningd/test/run-commit_tx.c: if (!derive_simple_privkey(&x_local_htlc_basepoint_secret,
lightningd/test/run-key_derive.c: if (!derive_simple_privkey(&base_secret, &base_point,
onchaind/onchain.c: if (!derive_simple_privkey(&secrets->delayed_payment_basepoint_secret,
onchaind/onchain.c: if (!derive_simple_privkey(&secrets->payment_basepoint_secret,
onchaind/onchain.c: if (!derive_simple_privkey(&secrets->htlc_basepoint_secret,
onchaind/onchain.c: if (!derive_simple_privkey(&secrets->payment_basepoint_secret,
onchaind/onchain.c: if (!derive_simple_privkey(&secrets->htlc_basepoint_secret,
```
Our handling of SIGPIPE was incoherent and inconsistent, and we had much
cut & paste between the daemons. They should *ALL* ignore SIGPIPE, and
much of the rest of the boilerplate can be shared, so should be.
Reported-by: @ZmnSCPxjFixes: #528
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
So far we have been generating the tx both in the HSM and in the
caller, and had to rely on them generating exactly the same
transaction. This makes it a lot simpler by fully signing and
serializing the TX on the HSM side and the caller just needs to unpack
and broadcast it.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
It's just a sha256_double, but importantly when we convert it to a
string (in type_to_string, which is used in logging) we use
bitcoin_blkid_to_hex() so it's reversed as people expect.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Firstly, not every output is a P2SH (our change outputs aren't, and in
future we'll have native incoming segwit txs).
Secondly, withdraw_tx() permutes the utxo array, so we can't use a
temporary: we got away with it because we were always using the same
key!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Change all calls to use the correct serialization and deserialization
functions, include the correct headers and remove the control
messages.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
We had a number of entry points into the HSM, all with different
behavior, so this is my attempt at unifying the way we handle
clients. Every client, except master, now takes the same path entry
point to the HSM and we use capability bit flags to indicate whether
the client is allowed to execute a set of operations.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
This change is really to allow us to have a --dev-fail-on-subdaemon-fail option
so we can handle failures from subdaemons generically.
It also neatens handling so we can have an explicit callback for "peer
did something wrong" (which matters if we want to close the channel in
that case).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
To avoid everything pulling in HTLCs stuff to the opening daemon, we
split the channel and commit_tx routines into initial_channel and
initial_commit_tx (no HTLC support) and move full HTLC supporting versions
into channeld.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
As per lightning-rfc change 956e8809d9d1ee87e31b855923579b96943d5e63
"BOLT 7: add chain_hashes values to channel_update and channel_announcment"
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rather a big commit, but I couldn't figure out how to split it
nicely. It introduces a new message from the channel to the master
signaling that the channel has been announced, so that the master can
take care of announcing the node itself. A provisorial announcement is
created and passed to the HSM, which signs it and passes it back to
the master. Finally the master injects it into gossipd which will take
care of broadcasting it.
We alternated between using a sha256 and using a privkey, but there are
numerous places where we have a random 32 bytes which are neither.
This fixes many of them (plus, struct privkey is now defined in terms of
struct secret).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Rusty Russell
practicalswift
conanoc
Christian Decker
ZmnSCPxj