The simplest case is to explicitly load it when we see it's been
set.
This involves neatening the default config setup, to remove it from
opt_parse_from_config() and into the caller. It also seems we don't
need to call it anymore before parsing early options: none of them
need ld->config set.
Closes: #3030
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For memory-usage reasons, struct chan doesn't use a tal destructor, in
favor of us calling free_chan in the right places.
In DEVELOPER mode, we should check that is the case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
There are some more #if DEVELOPER one-liners coming, this makes them
clear, but still lets them stand out.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We've been slack, but it's going to be important for testing
ratelimiting. And it currently has a minor memory leak.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Thanks clang! Here's the error:
ommon/wireaddr.c:359:14: error: variable 'addr' is used uninitialized whenever
'if' condition is false [-Werror,-Wsometimes-uninitialized]
} else if (addrinfo->ai_family == AF_INET6) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
common/wireaddr.c:364:25: note: uninitialized use occurs here
tal_arr_expand(addrs, addr);
^~~~
./common/utils.h:27:16: note: expanded from macro 'tal_arr_expand'
(*(p))[n] = (s); \
^
common/wireaddr.c:359:10: note: remove the 'if' if its condition is always true
} else if (addrinfo->ai_family == AF_INET6) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
common/wireaddr.c:354:3: note: variable 'addr' is declared here
struct wireaddr addr;
^
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
After switching to a plugin, we verify that we can fund a channel
before we check to contact a peer. We'll need to have a funded wallet
to pass the check in this test that verifies that 'fundchannel' cannot
be called for a peer after fundchannel_start is.
in order to preserve current behavior, we cap at max if specified 'all';
otherwise we fail since the amount requested is larger than the
channel max capacity
Previously, we'd fail on 'all'. `fundchannel_start` needs an amount
in order to start a funding transaction.
The way that we approach this is to first call `txprepare` with a
placeholder address and the 'all' amount; this will return the maximum
amount available. We then clamp this to the max_funding (currently
hardcoded, in the future we'd want to consult our/the peer's features) and
then use the amount on the output in the prepared transaction as the
funding amount. We then pass this amount to fundchannel_start,
after we've started it successfully we cancel the held placeholder
transaction and prepare a second transaction for the exact amount,
using the funding address that fundchannel_start passed back.
When the peer sends back an error, we return null, but sending
a NULL message back to lightningd causes a parsing error on their
side. negotiation_failed already calls back the peer, all we need
to do here is exit.
Allow a user to select the utxo set that will be added to a
transaction, via the `utxos` parameter. Optional.
Format for utxos should be of the form ["txid:vout","..."]
For now, we can't fully ensure that the broadcast was catched from a third pary. Only when the transaction (broadcast by a third pary) is onchain, we can catch it.
