2021-12-04 11:23:56 +00:00
|
|
|
#include "config.h"
|
|
|
|
|
#include <bitcoin/feerate.h>
|
2021-03-15 04:27:56 +00:00
|
|
|
#include <bitcoin/psbt.h>
|
2021-09-16 06:00:42 +01:00
|
|
|
#include <ccan/cast/cast.h>
|
2021-03-15 04:27:56 +00:00
|
|
|
#include <ccan/mem/mem.h>
|
2018-02-20 20:59:04 +00:00
|
|
|
#include <ccan/tal/str/str.h>
|
2019-05-22 22:20:14 +01:00
|
|
|
#include <common/addr.h>
|
2021-06-22 19:25:59 +01:00
|
|
|
#include <common/blockheight_states.h>
|
2021-09-16 06:00:42 +01:00
|
|
|
#include <common/configdir.h>
|
2019-12-12 17:18:25 +00:00
|
|
|
#include <common/fee_states.h>
|
2021-09-16 06:00:42 +01:00
|
|
|
#include <common/json_command.h>
|
2022-07-04 04:49:38 +01:00
|
|
|
#include <common/json_param.h>
|
lightningd: fix transient leak report when openingd shutting down.
```
> raiseValueError(str(errors))
E ValueError:
E Node errors:
E Global errors:
E - Node /tmp/ltests-x5sfpiwp/test_openchannel_hook_chaining_1/lightning-2/ has memory leaks: [
E {
E "backtrace": [
E "ccan/ccan/tal/tal.c:442 (tal_alloc_)",
E "ccan/ccan/io/io.c:91 (io_new_conn_)",
E "lightningd/subd.c:773 (new_subd)",
E "lightningd/subd.c:827 (new_channel_subd_)",
E "lightningd/opening_control.c:870 (peer_start_openingd)",
E "lightningd/peer_control.c:1307 (peer_active)",
E "lightningd/connect_control.c:457 (connectd_msg)",
E "lightningd/subd.c:556 (sd_msg_read)",
E "lightningd/subd.c:357 (read_fds)",
E "ccan/ccan/io/io.c:59 (next_plan)",
E "ccan/ccan/io/io.c:407 (do_plan)",
E "ccan/ccan/io/io.c:417 (io_ready)",
E "ccan/ccan/io/poll.c:453 (io_loop)",
E "lightningd/io_loop_with_timers.c:22 (io_loop_with_timers)",
E "lightningd/lightningd.c:1181 (main)",
E "../csu/libc-start.c:308 (__libc_start_main)"
E ],
E "label": "ccan/ccan/io/io.c:91:struct io_conn",
E "parents": [
E "lightningd/lightningd.c:107:struct lightningd"
E ],
E "value": "0x2b5a898"
E }
E ]
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-06-26 05:48:01 +01:00
|
|
|
#include <common/memleak.h>
|
2022-06-24 02:14:11 +01:00
|
|
|
#include <common/scb_wiregen.h>
|
2021-09-16 06:00:42 +01:00
|
|
|
#include <common/type_to_string.h>
|
2022-03-22 20:27:29 +00:00
|
|
|
#include <connectd/connectd_wiregen.h>
|
2018-02-20 20:59:04 +00:00
|
|
|
#include <errno.h>
|
2021-09-16 06:00:42 +01:00
|
|
|
#include <hsmd/capabilities.h>
|
2018-02-20 20:59:04 +00:00
|
|
|
#include <lightningd/chaintopology.h>
|
2021-09-16 06:00:42 +01:00
|
|
|
#include <lightningd/channel.h>
|
2018-02-20 20:59:09 +00:00
|
|
|
#include <lightningd/channel_control.h>
|
2018-02-20 20:59:04 +00:00
|
|
|
#include <lightningd/hsm_control.h>
|
2018-12-13 12:58:40 +00:00
|
|
|
#include <lightningd/notification.h>
|
2020-09-09 08:20:53 +01:00
|
|
|
#include <lightningd/opening_common.h>
|
2018-02-20 20:59:04 +00:00
|
|
|
#include <lightningd/opening_control.h>
|
2022-01-11 01:13:59 +00:00
|
|
|
#include <lightningd/peer_fd.h>
|
2019-05-20 23:45:20 +01:00
|
|
|
#include <lightningd/plugin_hook.h>
|
2018-02-20 20:59:04 +00:00
|
|
|
#include <lightningd/subd.h>
|
2020-08-25 03:12:18 +01:00
|
|
|
#include <openingd/openingd_wiregen.h>
|
2022-04-22 11:57:01 +01:00
|
|
|
#include <sodium/randombytes.h>
|
2021-09-16 06:00:42 +01:00
|
|
|
#include <wally_psbt.h>
|
2018-02-20 20:59:04 +00:00
|
|
|
|
2018-10-19 02:17:49 +01:00
|
|
|
void json_add_uncommitted_channel(struct json_stream *response,
|
2018-02-20 20:59:04 +00:00
|
|
|
const struct uncommitted_channel *uc)
|
|
|
|
|
{
|
2019-02-21 03:45:55 +00:00
|
|
|
struct amount_msat total, ours;
|
2018-02-20 20:59:04 +00:00
|
|
|
if (!uc)
|
|
|
|
|
return;
|
|
|
|
|
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
/* If we're chatting but no channel, that's shown by connected: True */
|
|
|
|
|
if (!uc->fc)
|
|
|
|
|
return;
|
|
|
|
|
|
2018-02-20 20:59:04 +00:00
|
|
|
json_object_start(response, NULL);
|
|
|
|
|
json_add_string(response, "state", "OPENINGD");
|
|
|
|
|
json_add_string(response, "owner", "lightning_openingd");
|
2021-06-16 02:00:17 +01:00
|
|
|
json_add_string(response, "opener", "local");
|
2018-02-23 05:53:47 +00:00
|
|
|
if (uc->transient_billboard) {
|
|
|
|
|
json_array_start(response, "status");
|
|
|
|
|
json_add_string(response, NULL, uc->transient_billboard);
|
|
|
|
|
json_array_end(response);
|
|
|
|
|
}
|
2018-02-20 20:59:04 +00:00
|
|
|
|
2019-02-21 03:45:55 +00:00
|
|
|
/* These should never fail. */
|
2021-10-13 04:45:36 +01:00
|
|
|
if (amount_sat_to_msat(&total, uc->fc->funding_sats)
|
2019-02-21 03:45:55 +00:00
|
|
|
&& amount_msat_sub(&ours, total, uc->fc->push)) {
|
2019-05-20 06:07:40 +01:00
|
|
|
json_add_amount_msat_compat(response, ours,
|
|
|
|
|
"msatoshi_to_us", "to_us_msat");
|
|
|
|
|
json_add_amount_msat_compat(response, total,
|
|
|
|
|
"msatoshi_total", "total_msat");
|
2019-02-21 03:45:55 +00:00
|
|
|
}
|
2020-08-21 02:57:20 +01:00
|
|
|
|
|
|
|
|
json_array_start(response, "features");
|
|
|
|
|
if (feature_negotiated(uc->peer->ld->our_features,
|
|
|
|
|
uc->peer->their_features,
|
|
|
|
|
OPT_STATIC_REMOTEKEY))
|
|
|
|
|
json_add_string(response, NULL, "option_static_remotekey");
|
|
|
|
|
|
|
|
|
|
if (feature_negotiated(uc->peer->ld->our_features,
|
|
|
|
|
uc->peer->their_features,
|
|
|
|
|
OPT_ANCHOR_OUTPUTS))
|
|
|
|
|
json_add_string(response, NULL, "option_anchor_outputs");
|
|
|
|
|
json_array_end(response);
|
2018-02-20 20:59:04 +00:00
|
|
|
json_object_end(response);
|
|
|
|
|
}
|
|
|
|
|
|
2018-03-07 00:06:07 +00:00
|
|
|
/* Steals fields from uncommitted_channel: returns NULL if can't generate a
|
|
|
|
|
* key for this channel (shouldn't happen!). */
|
2018-02-20 20:59:04 +00:00
|
|
|
static struct channel *
|
|
|
|
|
wallet_commit_channel(struct lightningd *ld,
|
|
|
|
|
struct uncommitted_channel *uc,
|
2020-09-09 08:20:53 +01:00
|
|
|
struct channel_id *cid,
|
2018-02-20 20:59:04 +00:00
|
|
|
struct bitcoin_tx *remote_commit,
|
2018-12-02 23:15:06 +00:00
|
|
|
struct bitcoin_signature *remote_commit_sig,
|
2021-10-13 04:45:36 +01:00
|
|
|
const struct bitcoin_outpoint *funding,
|
|
|
|
|
struct amount_sat funding_sats,
|
2019-02-21 03:45:55 +00:00
|
|
|
struct amount_msat push,
|
2018-02-20 20:59:04 +00:00
|
|
|
u8 channel_flags,
|
|
|
|
|
struct channel_info *channel_info,
|
2019-04-30 23:58:09 +01:00
|
|
|
u32 feerate,
|
2019-10-15 02:08:33 +01:00
|
|
|
const u8 *our_upfront_shutdown_script,
|
2021-09-10 03:14:16 +01:00
|
|
|
const u8 *remote_upfront_shutdown_script,
|
|
|
|
|
const struct channel_type *type)
|
2018-02-20 20:59:04 +00:00
|
|
|
{
|
|
|
|
|
struct channel *channel;
|
2019-02-21 03:45:55 +00:00
|
|
|
struct amount_msat our_msat;
|
2019-09-30 22:47:16 +01:00
|
|
|
struct amount_sat local_funding;
|
2018-03-07 00:06:07 +00:00
|
|
|
s64 final_key_idx;
|
2021-06-04 06:13:47 +01:00
|
|
|
u64 static_remotekey_start;
|
2021-06-22 19:25:59 +01:00
|
|
|
u32 lease_start_blockheight = 0; /* No leases on v1 */
|
2022-04-22 11:57:01 +01:00
|
|
|
struct short_channel_id *alias_local;
|
2022-07-06 16:01:58 +01:00
|
|
|
struct timeabs timestamp;
|
2018-03-07 00:06:07 +00:00
|
|
|
|
2020-10-08 09:01:09 +01:00
|
|
|
/* We cannot both be the fundee *and* have a `fundchannel_start`
|
|
|
|
|
* command running!
|
|
|
|
|
*/
|
|
|
|
|
assert(!(uc->got_offer && uc->fc));
|
|
|
|
|
|
2018-03-07 00:06:07 +00:00
|
|
|
/* Get a key to use for closing outputs from this tx */
|
|
|
|
|
final_key_idx = wallet_get_newindex(ld);
|
|
|
|
|
if (final_key_idx == -1) {
|
|
|
|
|
log_broken(uc->log, "Can't get final key index");
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
2018-02-20 20:59:04 +00:00
|
|
|
|
2019-02-21 03:45:55 +00:00
|
|
|
if (uc->fc) {
|
2021-10-13 04:45:36 +01:00
|
|
|
if (!amount_sat_sub_msat(&our_msat, funding_sats, push)) {
|
2019-02-21 03:45:55 +00:00
|
|
|
log_broken(uc->log, "push %s exceeds funding %s",
|
|
|
|
|
type_to_string(tmpctx, struct amount_msat,
|
|
|
|
|
&push),
|
|
|
|
|
type_to_string(tmpctx, struct amount_sat,
|
2021-10-13 04:45:36 +01:00
|
|
|
&funding_sats));
|
2019-02-21 03:45:55 +00:00
|
|
|
return NULL;
|
|
|
|
|
}
|
2021-10-13 04:45:36 +01:00
|
|
|
local_funding = funding_sats;
|
2019-09-30 22:47:16 +01:00
|
|
|
} else {
|
2019-02-21 03:45:55 +00:00
|
|
|
our_msat = push;
|
2019-09-30 22:47:16 +01:00
|
|
|
local_funding = AMOUNT_SAT(0);
|
|
|
|
|
}
|
2018-02-20 20:59:04 +00:00
|
|
|
|
|
|
|
|
/* old_remote_per_commit not valid yet, copy valid one. */
|
|
|
|
|
channel_info->old_remote_per_commit = channel_info->remote_per_commit;
|
|
|
|
|
|
2021-04-06 02:21:18 +01:00
|
|
|
/* BOLT #2:
|
2019-09-10 03:23:27 +01:00
|
|
|
* 1. type: 35 (`funding_signed`)
|
|
|
|
|
* 2. data:
|
|
|
|
|
* * [`channel_id`:`channel_id`]
|
|
|
|
|
* * [`signature`:`signature`]
|
|
|
|
|
*
|
|
|
|
|
* #### Requirements
|
|
|
|
|
*
|
|
|
|
|
* Both peers:
|
2021-09-08 01:09:14 +01:00
|
|
|
* ...
|
|
|
|
|
* - if `option_anchors_zero_fee_htlc_tx` was negotiated:
|
|
|
|
|
* - the `channel_type` is `option_anchors_zero_fee_htlc_tx` and
|
|
|
|
|
* `option_static_remotekey` (bits 22 and 12)
|
|
|
|
|
* - otherwise, if `option_anchor_outputs` was negotiated:
|
|
|
|
|
* - the `channel_type` is `option_anchor_outputs` and
|
|
|
|
|
* `option_static_remotekey` (bits 20 and 12)
|
|
|
|
|
* - otherwise, if `option_static_remotekey` was negotiated:
|
|
|
|
|
* - the `channel_type` is `option_static_remotekey` (bit 12)
|
2019-09-10 03:23:27 +01:00
|
|
|
* - otherwise:
|
2021-09-08 01:09:14 +01:00
|
|
|
* - the `channel_type` is empty
|
|
|
|
|
* - MUST use that `channel_type` for all commitment transactions.
|
2019-09-10 03:23:27 +01:00
|
|
|
*/
|
|
|
|
|
/* i.e. We set it now for the channel permanently. */
|
2021-09-09 06:29:35 +01:00
|
|
|
if (channel_type_has(type, OPT_STATIC_REMOTEKEY))
|
2021-06-04 06:13:47 +01:00
|
|
|
static_remotekey_start = 0;
|
|
|
|
|
else
|
|
|
|
|
static_remotekey_start = 0x7FFFFFFFFFFFFFFF;
|
|
|
|
|
|
2022-04-22 11:57:01 +01:00
|
|
|
alias_local = tal(NULL, struct short_channel_id);
|
|
|
|
|
randombytes_buf(alias_local, sizeof(struct short_channel_id));
|
|
|
|
|
|
2018-02-20 20:59:04 +00:00
|
|
|
channel = new_channel(uc->peer, uc->dbid,
|
|
|
|
|
NULL, /* No shachain yet */
|
|
|
|
|
CHANNELD_AWAITING_LOCKIN,
|
|
|
|
|
uc->fc ? LOCAL : REMOTE,
|
|
|
|
|
uc->log,
|
2018-02-23 05:53:47 +00:00
|
|
|
take(uc->transient_billboard),
|
2018-02-20 20:59:04 +00:00
|
|
|
channel_flags,
|
|
|
|
|
&uc->our_config,
|
|
|
|
|
uc->minimum_depth,
|
|
|
|
|
1, 1, 0,
|
2019-02-21 03:45:55 +00:00
|
|
|
funding,
|
2021-10-13 04:45:36 +01:00
|
|
|
funding_sats,
|
2019-02-21 03:45:55 +00:00
|
|
|
push,
|
2019-09-30 22:47:16 +01:00
|
|
|
local_funding,
|
2018-02-20 20:59:04 +00:00
|
|
|
false, /* !remote_funding_locked */
|
|
|
|
|
NULL, /* no scid yet */
|
2022-04-22 11:57:01 +01:00
|
|
|
alias_local, /* But maybe we have an alias we want to use? */
|
|
|
|
|
NULL, /* They haven't told us an alias yet */
|
2020-09-09 08:20:53 +01:00
|
|
|
cid,
|
2018-03-31 01:21:13 +01:00
|
|
|
/* The three arguments below are msatoshi_to_us,
|
|
|
|
|
* msatoshi_to_us_min, and msatoshi_to_us_max.
|
|
|
|
|
* Because, this is a newly-funded channel,
|
|
|
|
|
* all three are same value. */
|
2019-02-21 03:45:55 +00:00
|
|
|
our_msat,
|
|
|
|
|
our_msat, /* msat_to_us_min */
|
|
|
|
|
our_msat, /* msat_to_us_max */
|
2018-02-20 20:59:04 +00:00
|
|
|
remote_commit,
|
|
|
|
|
remote_commit_sig,
|
|
|
|
|
NULL, /* No HTLC sigs yet */
|
|
|
|
|
channel_info,
|
2020-09-17 02:58:59 +01:00
|
|
|
take(new_fee_states(NULL, uc->fc ? LOCAL : REMOTE,
|
|
|
|
|
&feerate)),
|
2019-09-29 08:35:45 +01:00
|
|
|
NULL, /* No shutdown_scriptpubkey[REMOTE] yet */
|
2019-10-15 02:08:33 +01:00
|
|
|
our_upfront_shutdown_script,
|
2018-03-07 00:06:07 +00:00
|
|
|
final_key_idx, false,
|
2018-02-20 20:59:04 +00:00
|
|
|
NULL, /* No commit sent yet */
|
2018-08-02 07:49:56 +01:00
|
|
|
/* If we're fundee, could be a little before this
|
|
|
|
|
* in theory, but it's only used for timing out. */
|
2020-08-03 12:26:44 +01:00
|
|
|
get_network_blockheight(ld->topology),
|
2018-04-26 05:51:01 +01:00
|
|
|
feerate, feerate,
|
2018-07-23 03:23:02 +01:00
|
|
|
&uc->local_basepoints,
|
2018-08-17 06:06:36 +01:00
|
|
|
&uc->local_funding_pubkey,
|
2019-02-21 00:01:33 +00:00
|
|
|
NULL,
|
|
|
|
|
ld->config.fee_base,
|
2019-04-30 23:57:09 +01:00
|
|
|
ld->config.fee_per_satoshi,
|
2019-09-10 03:22:27 +01:00
|
|
|
remote_upfront_shutdown_script,
|
2021-06-04 06:13:47 +01:00
|
|
|
static_remotekey_start, static_remotekey_start,
|
2021-09-09 06:29:35 +01:00
|
|
|
type,
|
2020-10-28 10:46:17 +00:00
|
|
|
NUM_SIDES, /* closer not yet known */
|
2021-03-15 20:25:41 +00:00
|
|
|
uc->fc ? REASON_USER : REASON_REMOTE,
|
2021-06-17 02:28:18 +01:00
|
|
|
NULL,
|
2021-06-22 19:25:59 +01:00
|
|
|
take(new_height_states(NULL, uc->fc ? LOCAL : REMOTE,
|
|
|
|
|
&lease_start_blockheight)),
|
2022-03-21 00:58:23 +00:00
|
|
|
0, NULL, 0, 0, /* No leases on v1s */
|
2022-03-26 13:31:26 +00:00
|
|
|
ld->config.htlc_minimum_msat,
|
|
|
|
|
ld->config.htlc_maximum_msat);
|
2018-02-20 20:59:04 +00:00
|
|
|
|
|
|
|
|
/* Now we finally put it in the database. */
|
|
|
|
|
wallet_channel_insert(ld->wallet, channel);
|
|
|
|
|
|
2022-07-06 16:01:58 +01:00
|
|
|
/* Notify that channel state changed (from non existant to existant) */
|
|
|
|
|
timestamp = time_now();
|
|
|
|
|
notify_channel_state_changed(ld, &channel->peer->id,
|
|
|
|
|
&channel->cid,
|
|
|
|
|
channel->scid, /* NULL */
|
|
|
|
|
×tamp,
|
|
|
|
|
0, /* No prior state */
|
|
|
|
|
channel->state,
|
|
|
|
|
channel->state_change_cause,
|
|
|
|
|
"new channel opened");
|
|
|
|
|
|
2018-02-20 20:59:04 +00:00
|
|
|
return channel;
|
|
|
|
|
}
|
|
|
|
|
|
lightningd/opening_control.c: Remove 'Try fundchannel_cancel again' error.
Changelog-Changed: `fundchannel_cancel` will now succeed even when executed while a `fundchannel_complete` is ongoing; in that case, it will be considered as cancelling the funding *after* the `fundchannel_complete` succeeds.
Let me introduce the concept of "Sequential Consistency":
All operations on parallel processes form a single total order agreed upon by all processes.
So for example, suppose we have parallel invocations of `fundchannel_complete` and `fundchannel_cancel`:
+--[fundchannel_complete]-->
|
--[fundchannel_start]-+
|
+--[fundchannel_cancel]---->
What "Sequential Consistency" means is that the above parallel operations can be serialized as a single total order as:
--[fundchannel_start]--[fundchannel_complete]--[fundchannel_cancel]-->
Or:
--[fundchannel_start]--[fundchannel_cancel]--[fundchannel_complete]-->
In the first case, `fundchannel_complete` succeeds, and the `fundchannel_cancel` invocation also succeeds, sending an `error` to the peer to make them forget the chanel.
In the second case, `fundchannel_cancel` succeeds, and the succeeding `fundchannel_complete` invocation fails, since the funding is already cancelled and there is nothing to complete.
Note that in both cases, `fundchannel_cancel` **always** succeeds.
Unfortunately, prior to this commit, `fundchannel_cancel` could fail with a `Try fundchannel_cancel again` error if the `fundchannel_complete` is ongoing when the `fundchannel_cancel` is initiated.
This violates Sequential Consistency, as there is no single total order that would have caused `fundchannel_cancel` to fail.
This commit is a minimal patch which just reschedules `fundchannel_cancel` to occur after any `fundchannel_complete` that is ongoing.
2020-06-18 04:49:17 +01:00
|
|
|
/** cancel_after_fundchannel_complete_success
|
|
|
|
|
*
|
|
|
|
|
* @brief Called to cancel a `fundchannel` after
|
|
|
|
|
* a `fundchannel_complete` succeeds.
|
|
|
|
|
*
|
|
|
|
|
* @desc Specifically, this is called when a
|
|
|
|
|
* `fundchannel_cancel` is blocked due to a
|
|
|
|
|
* parallel `fundchannel_complete` still running.
|
|
|
|
|
* After the `fundchannel_complete` succeeds, we
|
|
|
|
|
* invoke this function to cancel the funding
|
|
|
|
|
* after all.
|
|
|
|
|
*
|
|
|
|
|
* In effect, this forces the `fundchannel_cancel`
|
|
|
|
|
* to be invoked after the `fundchannel_complete`
|
|
|
|
|
* succeeds, leading to a reasonable serial
|
|
|
|
|
* execution.
|
|
|
|
|
*
|
|
|
|
|
* @param cmd - The `fundchannel_cancel` command
|
|
|
|
|
* that wants to cancel this.
|
|
|
|
|
* @param channel - The channel being cancelled.
|
|
|
|
|
*/
|
|
|
|
|
static void
|
|
|
|
|
cancel_after_fundchannel_complete_success(struct command *cmd,
|
|
|
|
|
struct channel *channel)
|
|
|
|
|
{
|
2020-06-24 05:34:26 +01:00
|
|
|
was_pending(cancel_channel_before_broadcast(cmd, channel->peer));
|
lightningd/opening_control.c: Remove 'Try fundchannel_cancel again' error.
Changelog-Changed: `fundchannel_cancel` will now succeed even when executed while a `fundchannel_complete` is ongoing; in that case, it will be considered as cancelling the funding *after* the `fundchannel_complete` succeeds.
Let me introduce the concept of "Sequential Consistency":
All operations on parallel processes form a single total order agreed upon by all processes.
So for example, suppose we have parallel invocations of `fundchannel_complete` and `fundchannel_cancel`:
+--[fundchannel_complete]-->
|
--[fundchannel_start]-+
|
+--[fundchannel_cancel]---->
What "Sequential Consistency" means is that the above parallel operations can be serialized as a single total order as:
--[fundchannel_start]--[fundchannel_complete]--[fundchannel_cancel]-->
Or:
--[fundchannel_start]--[fundchannel_cancel]--[fundchannel_complete]-->
In the first case, `fundchannel_complete` succeeds, and the `fundchannel_cancel` invocation also succeeds, sending an `error` to the peer to make them forget the chanel.
In the second case, `fundchannel_cancel` succeeds, and the succeeding `fundchannel_complete` invocation fails, since the funding is already cancelled and there is nothing to complete.
Note that in both cases, `fundchannel_cancel` **always** succeeds.
Unfortunately, prior to this commit, `fundchannel_cancel` could fail with a `Try fundchannel_cancel again` error if the `fundchannel_complete` is ongoing when the `fundchannel_cancel` is initiated.
This violates Sequential Consistency, as there is no single total order that would have caused `fundchannel_cancel` to fail.
This commit is a minimal patch which just reschedules `fundchannel_cancel` to occur after any `fundchannel_complete` that is ongoing.
2020-06-18 04:49:17 +01:00
|
|
|
}
|
|
|
|
|
|
2019-05-31 22:46:04 +01:00
|
|
|
static void funding_success(struct channel *channel)
|
|
|
|
|
{
|
|
|
|
|
struct json_stream *response;
|
2020-09-09 08:20:53 +01:00
|
|
|
struct funding_channel *fc =
|
|
|
|
|
channel->peer->uncommitted_channel->fc;
|
2019-05-31 22:46:04 +01:00
|
|
|
struct command *cmd = fc->cmd;
|
|
|
|
|
|
lightningd/opening_control.c: Remove 'Try fundchannel_cancel again' error.
Changelog-Changed: `fundchannel_cancel` will now succeed even when executed while a `fundchannel_complete` is ongoing; in that case, it will be considered as cancelling the funding *after* the `fundchannel_complete` succeeds.
Let me introduce the concept of "Sequential Consistency":
All operations on parallel processes form a single total order agreed upon by all processes.
So for example, suppose we have parallel invocations of `fundchannel_complete` and `fundchannel_cancel`:
+--[fundchannel_complete]-->
|
--[fundchannel_start]-+
|
+--[fundchannel_cancel]---->
What "Sequential Consistency" means is that the above parallel operations can be serialized as a single total order as:
--[fundchannel_start]--[fundchannel_complete]--[fundchannel_cancel]-->
Or:
--[fundchannel_start]--[fundchannel_cancel]--[fundchannel_complete]-->
In the first case, `fundchannel_complete` succeeds, and the `fundchannel_cancel` invocation also succeeds, sending an `error` to the peer to make them forget the chanel.
In the second case, `fundchannel_cancel` succeeds, and the succeeding `fundchannel_complete` invocation fails, since the funding is already cancelled and there is nothing to complete.
Note that in both cases, `fundchannel_cancel` **always** succeeds.
Unfortunately, prior to this commit, `fundchannel_cancel` could fail with a `Try fundchannel_cancel again` error if the `fundchannel_complete` is ongoing when the `fundchannel_cancel` is initiated.
This violates Sequential Consistency, as there is no single total order that would have caused `fundchannel_cancel` to fail.
This commit is a minimal patch which just reschedules `fundchannel_cancel` to occur after any `fundchannel_complete` that is ongoing.
2020-06-18 04:49:17 +01:00
|
|
|
/* Well, those cancels now need to trigger! */
|
2019-06-13 05:26:51 +01:00
|
|
|
for (size_t i = 0; i < tal_count(fc->cancels); i++)
|
lightningd/opening_control.c: Remove 'Try fundchannel_cancel again' error.
Changelog-Changed: `fundchannel_cancel` will now succeed even when executed while a `fundchannel_complete` is ongoing; in that case, it will be considered as cancelling the funding *after* the `fundchannel_complete` succeeds.
Let me introduce the concept of "Sequential Consistency":
All operations on parallel processes form a single total order agreed upon by all processes.
So for example, suppose we have parallel invocations of `fundchannel_complete` and `fundchannel_cancel`:
+--[fundchannel_complete]-->
|
--[fundchannel_start]-+
|
+--[fundchannel_cancel]---->
What "Sequential Consistency" means is that the above parallel operations can be serialized as a single total order as:
--[fundchannel_start]--[fundchannel_complete]--[fundchannel_cancel]-->
Or:
--[fundchannel_start]--[fundchannel_cancel]--[fundchannel_complete]-->
In the first case, `fundchannel_complete` succeeds, and the `fundchannel_cancel` invocation also succeeds, sending an `error` to the peer to make them forget the chanel.
In the second case, `fundchannel_cancel` succeeds, and the succeeding `fundchannel_complete` invocation fails, since the funding is already cancelled and there is nothing to complete.
Note that in both cases, `fundchannel_cancel` **always** succeeds.
Unfortunately, prior to this commit, `fundchannel_cancel` could fail with a `Try fundchannel_cancel again` error if the `fundchannel_complete` is ongoing when the `fundchannel_cancel` is initiated.
This violates Sequential Consistency, as there is no single total order that would have caused `fundchannel_cancel` to fail.
This commit is a minimal patch which just reschedules `fundchannel_cancel` to occur after any `fundchannel_complete` that is ongoing.
2020-06-18 04:49:17 +01:00
|
|
|
cancel_after_fundchannel_complete_success(fc->cancels[i],
|
|
|
|
|
channel);
|
2019-06-13 05:26:51 +01:00
|
|
|
|
2019-05-31 22:46:04 +01:00
|
|
|
response = json_stream_success(cmd);
|
|
|
|
|
json_add_string(response, "channel_id",
|
2020-09-09 08:20:53 +01:00
|
|
|
type_to_string(tmpctx, struct channel_id,
|
|
|
|
|
&channel->cid));
|
2019-05-31 22:46:04 +01:00
|
|
|
json_add_bool(response, "commitments_secured", true);
|
|
|
|
|
was_pending(command_success(cmd, response));
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-15 03:40:44 +00:00
|
|
|
static void funding_started_success(struct funding_channel *fc)
|
2019-05-22 00:51:52 +01:00
|
|
|
{
|
2019-05-23 00:25:22 +01:00
|
|
|
struct json_stream *response;
|
|
|
|
|
struct command *cmd = fc->cmd;
|
|
|
|
|
char *out;
|
|
|
|
|
|
|
|
|
|
response = json_stream_success(cmd);
|
|
|
|
|
out = encode_scriptpubkey_to_addr(cmd,
|
2019-10-15 11:58:30 +01:00
|
|
|
chainparams,
|
2021-03-15 03:40:44 +00:00
|
|
|
fc->funding_scriptpubkey);
|
2019-08-28 04:33:55 +01:00
|
|
|
if (out) {
|
2019-05-23 00:25:22 +01:00
|
|
|
json_add_string(response, "funding_address", out);
|
2021-03-15 03:40:44 +00:00
|
|
|
json_add_hex_talarr(response, "scriptpubkey",
|
|
|
|
|
fc->funding_scriptpubkey);
|
2019-10-15 02:08:33 +01:00
|
|
|
if (fc->our_upfront_shutdown_script)
|
|
|
|
|
json_add_hex_talarr(response, "close_to", fc->our_upfront_shutdown_script);
|
2022-03-20 15:07:48 +00:00
|
|
|
json_add_string(response, "warning_usage",
|
|
|
|
|
"The funding transaction MUST NOT be broadcast until after channel establishment has been successfully completed by running `fundchannel_complete`");
|
2019-08-28 04:33:55 +01:00
|
|
|
}
|
2019-06-12 07:23:24 +01:00
|
|
|
|
|
|
|
|
/* Clear this so cancel doesn't think it's still in progress */
|
|
|
|
|
fc->cmd = NULL;
|
2019-05-23 00:25:22 +01:00
|
|
|
was_pending(command_success(cmd, response));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void opening_funder_start_replied(struct subd *openingd, const u8 *resp,
|
|
|
|
|
const int *fds,
|
|
|
|
|
struct funding_channel *fc)
|
|
|
|
|
{
|
2019-10-15 02:08:33 +01:00
|
|
|
bool supports_shutdown_script;
|
2019-05-23 00:25:22 +01:00
|
|
|
|
2021-09-10 03:14:16 +01:00
|
|
|
if (!fromwire_openingd_funder_start_reply(fc, resp,
|
|
|
|
|
&fc->funding_scriptpubkey,
|
|
|
|
|
&supports_shutdown_script,
|
|
|
|
|
&fc->channel_type)) {
|
2019-05-23 00:25:22 +01:00
|
|
|
log_broken(fc->uc->log,
|
|
|
|
|
"bad OPENING_FUNDER_REPLY %s",
|
|
|
|
|
tal_hex(resp, resp));
|
|
|
|
|
was_pending(command_fail(fc->cmd, LIGHTNINGD,
|
|
|
|
|
"bad OPENING_FUNDER_REPLY %s",
|
|
|
|
|
tal_hex(fc->cmd, resp)));
|
|
|
|
|
goto failed;
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-15 02:08:33 +01:00
|
|
|
/* If we're not using the upfront shutdown script, forget it */
|
|
|
|
|
if (!supports_shutdown_script)
|
|
|
|
|
fc->our_upfront_shutdown_script =
|
|
|
|
|
tal_free(fc->our_upfront_shutdown_script);
|
|
|
|
|
|
2021-03-15 03:40:44 +00:00
|
|
|
funding_started_success(fc);
|
2019-05-31 22:40:31 +01:00
|
|
|
|
|
|
|
|
/* Mark that we're in-flight */
|
|
|
|
|
fc->inflight = true;
|
2019-05-23 00:25:22 +01:00
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
failed:
|
2021-12-27 23:21:09 +00:00
|
|
|
/* Frees fc too */
|
2019-05-23 00:25:22 +01:00
|
|
|
tal_free(fc->uc);
|
2019-05-22 00:51:52 +01:00
|
|
|
}
|
|
|
|
|
|
2019-05-31 22:46:04 +01:00
|
|
|
static void opening_funder_finished(struct subd *openingd, const u8 *resp,
|
|
|
|
|
const int *fds,
|
|
|
|
|
struct funding_channel *fc)
|
|
|
|
|
{
|
|
|
|
|
struct channel_info channel_info;
|
2020-09-09 08:20:53 +01:00
|
|
|
struct channel_id cid;
|
2021-10-13 04:45:36 +01:00
|
|
|
struct bitcoin_outpoint funding;
|
2019-05-31 22:46:04 +01:00
|
|
|
struct bitcoin_signature remote_commit_sig;
|
|
|
|
|
struct bitcoin_tx *remote_commit;
|
|
|
|
|
u32 feerate;
|
|
|
|
|
struct channel *channel;
|
|
|
|
|
struct lightningd *ld = openingd->ld;
|
|
|
|
|
u8 *remote_upfront_shutdown_script;
|
2022-01-11 01:13:59 +00:00
|
|
|
struct peer_fd *peer_fd;
|
2020-05-07 01:43:42 +01:00
|
|
|
struct penalty_base *pbase;
|
2021-09-10 03:14:16 +01:00
|
|
|
struct channel_type *type;
|
2019-05-31 22:46:04 +01:00
|
|
|
|
|
|
|
|
/* This is a new channel_info.their_config so set its ID to 0 */
|
|
|
|
|
channel_info.their_config.id = 0;
|
|
|
|
|
|
2020-08-25 03:12:18 +01:00
|
|
|
if (!fromwire_openingd_funder_reply(resp, resp,
|
2019-05-31 22:46:04 +01:00
|
|
|
&channel_info.their_config,
|
|
|
|
|
&remote_commit,
|
2020-05-07 01:43:42 +01:00
|
|
|
&pbase,
|
2019-05-31 22:46:04 +01:00
|
|
|
&remote_commit_sig,
|
|
|
|
|
&channel_info.theirbase.revocation,
|
|
|
|
|
&channel_info.theirbase.payment,
|
|
|
|
|
&channel_info.theirbase.htlc,
|
|
|
|
|
&channel_info.theirbase.delayed_payment,
|
|
|
|
|
&channel_info.remote_per_commit,
|
|
|
|
|
&fc->uc->minimum_depth,
|
|
|
|
|
&channel_info.remote_fundingkey,
|
2021-10-13 04:45:36 +01:00
|
|
|
&funding,
|
2019-05-31 22:46:04 +01:00
|
|
|
&feerate,
|
|
|
|
|
&fc->uc->our_config.channel_reserve,
|
2021-09-10 03:14:16 +01:00
|
|
|
&remote_upfront_shutdown_script,
|
|
|
|
|
&type)) {
|
2019-05-31 22:46:04 +01:00
|
|
|
log_broken(fc->uc->log,
|
|
|
|
|
"bad OPENING_FUNDER_REPLY %s",
|
|
|
|
|
tal_hex(resp, resp));
|
|
|
|
|
was_pending(command_fail(fc->cmd, LIGHTNINGD,
|
|
|
|
|
"bad OPENING_FUNDER_REPLY %s",
|
|
|
|
|
tal_hex(fc->cmd, resp)));
|
|
|
|
|
goto cleanup;
|
|
|
|
|
}
|
2019-10-15 11:58:30 +01:00
|
|
|
remote_commit->chainparams = chainparams;
|
2022-01-08 13:29:29 +00:00
|
|
|
|
2022-01-11 01:13:59 +00:00
|
|
|
peer_fd = new_peer_fd_arr(resp, fds);
|
2019-05-31 22:46:04 +01:00
|
|
|
|
|
|
|
|
log_debug(ld->log,
|
|
|
|
|
"%s", type_to_string(tmpctx, struct pubkey,
|
|
|
|
|
&channel_info.remote_per_commit));
|
|
|
|
|
|
2020-09-09 08:20:53 +01:00
|
|
|
/* Saved with channel to disk */
|
2021-10-13 04:45:36 +01:00
|
|
|
derive_channel_id(&cid, &funding);
|
2020-09-09 08:20:53 +01:00
|
|
|
|
2020-09-17 03:00:33 +01:00
|
|
|
/* old_remote_per_commit not valid yet, copy valid one. */
|
|
|
|
|
channel_info.old_remote_per_commit = channel_info.remote_per_commit;
|
|
|
|
|
|
2019-05-31 22:46:04 +01:00
|
|
|
/* Steals fields from uc */
|
|
|
|
|
channel = wallet_commit_channel(ld, fc->uc,
|
2020-09-09 08:20:53 +01:00
|
|
|
&cid,
|
2019-05-31 22:46:04 +01:00
|
|
|
remote_commit,
|
|
|
|
|
&remote_commit_sig,
|
2021-10-13 04:45:36 +01:00
|
|
|
&funding,
|
|
|
|
|
fc->funding_sats,
|
2019-05-31 22:46:04 +01:00
|
|
|
fc->push,
|
|
|
|
|
fc->channel_flags,
|
|
|
|
|
&channel_info,
|
|
|
|
|
feerate,
|
2019-10-15 02:08:33 +01:00
|
|
|
fc->our_upfront_shutdown_script,
|
2021-09-10 03:14:16 +01:00
|
|
|
remote_upfront_shutdown_script,
|
|
|
|
|
type);
|
2019-05-31 22:46:04 +01:00
|
|
|
if (!channel) {
|
|
|
|
|
was_pending(command_fail(fc->cmd, LIGHTNINGD,
|
|
|
|
|
"Key generation failure"));
|
|
|
|
|
goto cleanup;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Watch for funding confirms */
|
|
|
|
|
channel_watch_funding(ld, channel);
|
|
|
|
|
|
2020-05-07 01:49:38 +01:00
|
|
|
if (pbase)
|
|
|
|
|
wallet_penalty_base_add(ld->wallet, channel->dbid, pbase);
|
|
|
|
|
|
2019-08-28 22:28:26 +01:00
|
|
|
funding_success(channel);
|
2022-01-11 01:13:59 +00:00
|
|
|
peer_start_channeld(channel, peer_fd, NULL, false, NULL);
|
2018-02-20 20:59:04 +00:00
|
|
|
|
2019-05-31 22:46:04 +01:00
|
|
|
cleanup:
|
2021-12-27 23:21:09 +00:00
|
|
|
/* Frees fc too */
|
2018-02-20 20:59:04 +00:00
|
|
|
tal_free(fc->uc);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void opening_fundee_finished(struct subd *openingd,
|
|
|
|
|
const u8 *reply,
|
|
|
|
|
const int *fds,
|
|
|
|
|
struct uncommitted_channel *uc)
|
|
|
|
|
{
|
2020-09-09 11:10:28 +01:00
|
|
|
const u8 *fwd_msg;
|
2018-02-20 20:59:04 +00:00
|
|
|
struct channel_info channel_info;
|
2018-12-02 23:15:06 +00:00
|
|
|
struct bitcoin_signature remote_commit_sig;
|
2018-02-20 20:59:04 +00:00
|
|
|
struct bitcoin_tx *remote_commit;
|
2020-09-09 08:20:53 +01:00
|
|
|
struct channel_id cid;
|
2018-02-20 20:59:04 +00:00
|
|
|
struct lightningd *ld = openingd->ld;
|
2021-10-13 04:45:36 +01:00
|
|
|
struct bitcoin_outpoint funding;
|
|
|
|
|
struct amount_sat funding_sats;
|
2019-02-21 03:45:55 +00:00
|
|
|
struct amount_msat push;
|
2018-02-20 20:59:04 +00:00
|
|
|
u32 feerate;
|
|
|
|
|
u8 channel_flags;
|
|
|
|
|
struct channel *channel;
|
2019-11-21 00:47:44 +00:00
|
|
|
u8 *remote_upfront_shutdown_script, *local_upfront_shutdown_script;
|
2022-01-11 01:13:59 +00:00
|
|
|
struct peer_fd *peer_fd;
|
2020-05-07 01:43:42 +01:00
|
|
|
struct penalty_base *pbase;
|
2021-09-10 03:14:16 +01:00
|
|
|
struct channel_type *type;
|
2018-02-20 20:59:04 +00:00
|
|
|
|
|
|
|
|
log_debug(uc->log, "Got opening_fundee_finish_response");
|
|
|
|
|
|
|
|
|
|
/* This is a new channel_info.their_config, set its ID to 0 */
|
|
|
|
|
channel_info.their_config.id = 0;
|
|
|
|
|
|
2022-01-11 01:13:59 +00:00
|
|
|
peer_fd = new_peer_fd_arr(tmpctx, fds);
|
2020-08-25 03:12:18 +01:00
|
|
|
if (!fromwire_openingd_fundee(tmpctx, reply,
|
2020-05-07 01:43:42 +01:00
|
|
|
&channel_info.their_config,
|
|
|
|
|
&remote_commit,
|
|
|
|
|
&pbase,
|
|
|
|
|
&remote_commit_sig,
|
|
|
|
|
&channel_info.theirbase.revocation,
|
|
|
|
|
&channel_info.theirbase.payment,
|
|
|
|
|
&channel_info.theirbase.htlc,
|
|
|
|
|
&channel_info.theirbase.delayed_payment,
|
|
|
|
|
&channel_info.remote_per_commit,
|
|
|
|
|
&channel_info.remote_fundingkey,
|
|
|
|
|
&funding,
|
2021-10-13 04:45:36 +01:00
|
|
|
&funding_sats,
|
2020-05-07 01:43:42 +01:00
|
|
|
&push,
|
|
|
|
|
&channel_flags,
|
|
|
|
|
&feerate,
|
2020-09-09 11:10:28 +01:00
|
|
|
cast_const2(u8 **, &fwd_msg),
|
2020-05-07 01:43:42 +01:00
|
|
|
&uc->our_config.channel_reserve,
|
|
|
|
|
&local_upfront_shutdown_script,
|
2021-09-10 03:14:16 +01:00
|
|
|
&remote_upfront_shutdown_script,
|
|
|
|
|
&type)) {
|
2018-02-20 20:59:04 +00:00
|
|
|
log_broken(uc->log, "bad OPENING_FUNDEE_REPLY %s",
|
|
|
|
|
tal_hex(reply, reply));
|
2020-03-25 04:26:44 +00:00
|
|
|
uncommitted_channel_disconnect(uc, LOG_BROKEN,
|
|
|
|
|
"bad OPENING_FUNDEE_REPLY");
|
2018-08-09 01:25:29 +01:00
|
|
|
goto failed;
|
2018-02-20 20:59:04 +00:00
|
|
|
}
|
2019-07-30 21:04:55 +01:00
|
|
|
|
2019-10-15 11:58:30 +01:00
|
|
|
remote_commit->chainparams = chainparams;
|
2018-02-20 20:59:04 +00:00
|
|
|
|
2021-10-13 04:45:36 +01:00
|
|
|
derive_channel_id(&cid, &funding);
|
2020-09-09 08:20:53 +01:00
|
|
|
|
2020-09-17 03:00:33 +01:00
|
|
|
/* old_remote_per_commit not valid yet, copy valid one. */
|
|
|
|
|
channel_info.old_remote_per_commit = channel_info.remote_per_commit;
|
|
|
|
|
|
2018-02-20 20:59:04 +00:00
|
|
|
/* Consumes uc */
|
|
|
|
|
channel = wallet_commit_channel(ld, uc,
|
2020-09-09 08:20:53 +01:00
|
|
|
&cid,
|
2018-02-20 20:59:04 +00:00
|
|
|
remote_commit,
|
|
|
|
|
&remote_commit_sig,
|
2021-10-13 04:45:36 +01:00
|
|
|
&funding,
|
|
|
|
|
funding_sats,
|
2019-02-21 03:45:55 +00:00
|
|
|
push,
|
2018-02-20 20:59:04 +00:00
|
|
|
channel_flags,
|
|
|
|
|
&channel_info,
|
2019-04-30 23:58:09 +01:00
|
|
|
feerate,
|
2019-11-21 00:47:44 +00:00
|
|
|
local_upfront_shutdown_script,
|
2021-09-10 03:14:16 +01:00
|
|
|
remote_upfront_shutdown_script,
|
|
|
|
|
type);
|
2018-03-07 00:06:07 +00:00
|
|
|
if (!channel) {
|
2020-03-25 04:26:44 +00:00
|
|
|
uncommitted_channel_disconnect(uc, LOG_BROKEN,
|
|
|
|
|
"Commit channel failed");
|
2018-08-09 01:25:29 +01:00
|
|
|
goto failed;
|
2018-03-07 00:06:07 +00:00
|
|
|
}
|
2018-02-20 20:59:04 +00:00
|
|
|
|
|
|
|
|
log_debug(channel->log, "Watching funding tx %s",
|
2019-10-01 00:32:15 +01:00
|
|
|
type_to_string(reply, struct bitcoin_txid,
|
2021-10-13 04:45:36 +01:00
|
|
|
&channel->funding.txid));
|
2018-02-20 20:59:04 +00:00
|
|
|
|
|
|
|
|
channel_watch_funding(ld, channel);
|
|
|
|
|
|
2019-07-25 15:11:44 +01:00
|
|
|
/* Tell plugins about the success */
|
2021-10-13 04:45:36 +01:00
|
|
|
notify_channel_opened(ld, &channel->peer->id, &channel->funding_sats,
|
|
|
|
|
&channel->funding.txid, &channel->remote_funding_locked);
|
2019-07-25 15:11:44 +01:00
|
|
|
|
2020-05-07 01:49:38 +01:00
|
|
|
if (pbase)
|
|
|
|
|
wallet_penalty_base_add(ld->wallet, channel->dbid, pbase);
|
|
|
|
|
|
2018-02-20 20:59:04 +00:00
|
|
|
/* On to normal operation! */
|
2022-01-11 01:13:59 +00:00
|
|
|
peer_start_channeld(channel, peer_fd, fwd_msg, false, NULL);
|
2018-02-20 20:59:04 +00:00
|
|
|
|
|
|
|
|
tal_free(uc);
|
2018-08-09 01:25:29 +01:00
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
failed:
|
|
|
|
|
tal_free(uc);
|
2018-02-20 20:59:04 +00:00
|
|
|
}
|
|
|
|
|
|
2020-10-08 09:01:09 +01:00
|
|
|
static void
|
|
|
|
|
opening_funder_failed_cancel_commands(struct uncommitted_channel *uc,
|
|
|
|
|
const char *desc)
|
|
|
|
|
{
|
|
|
|
|
/* If no funding command(s) pending, do nothing. */
|
|
|
|
|
if (!uc->fc)
|
|
|
|
|
return;
|
|
|
|
|
|
2019-06-13 05:26:51 +01:00
|
|
|
/* Tell anyone who was trying to cancel */
|
|
|
|
|
for (size_t i = 0; i < tal_count(uc->fc->cancels); i++) {
|
2019-06-13 05:26:56 +01:00
|
|
|
struct json_stream *response;
|
|
|
|
|
|
|
|
|
|
response = json_stream_success(uc->fc->cancels[i]);
|
|
|
|
|
json_add_string(response, "cancelled", desc);
|
|
|
|
|
was_pending(command_success(uc->fc->cancels[i], response));
|
2019-05-31 22:51:56 +01:00
|
|
|
}
|
2018-08-09 01:25:29 +01:00
|
|
|
|
2019-06-13 05:26:51 +01:00
|
|
|
/* Tell any fundchannel_complete or fundchannel command */
|
|
|
|
|
if (uc->fc->cmd)
|
|
|
|
|
was_pending(command_fail(uc->fc->cmd, LIGHTNINGD, "%s", desc));
|
|
|
|
|
|
2018-08-09 01:25:29 +01:00
|
|
|
/* Clear uc->fc, so we can try again, and so we don't fail twice
|
2020-10-08 09:01:09 +01:00
|
|
|
* if they close.
|
|
|
|
|
* This code is also used in the case where we turn out to already
|
|
|
|
|
* be the fundee, in which case we should not have any `fc` at all,
|
|
|
|
|
* so we definitely should clear this.
|
|
|
|
|
*/
|
2018-08-09 01:25:29 +01:00
|
|
|
uc->fc = tal_free(uc->fc);
|
|
|
|
|
}
|
2022-03-22 20:26:29 +00:00
|
|
|
|
|
|
|
|
static void openingd_failed(struct subd *openingd, const u8 *msg,
|
|
|
|
|
struct uncommitted_channel *uc)
|
2020-10-17 01:05:56 +01:00
|
|
|
{
|
|
|
|
|
char *desc;
|
|
|
|
|
|
lightningd: mark subd->conn notleak() properly in transition.
Since subd is temporarily unreferenced, and our leak detection goes up
to the highest unreferenced parent, it complains about openingd->conn.
The correct fix is to catch this where we detach the subd:
```
DEBUG:root:{
"id": 1,
"result": {
"leaks": [
{
"value": "0x556e0445d8f8",
"label": "ccan/ccan/io/io.c:91:struct io_conn",
"backtrace": [
"ccan/ccan/tal/tal.c:442 (tal_alloc_)",
"ccan/ccan/io/io.c:91 (io_new_conn_)",
"lightningd/subd.c:774 (new_subd)",
"lightningd/subd.c:828 (new_channel_subd_)",
"lightningd/opening_control.c:872 (peer_start_openingd)",
"lightningd/peer_control.c:1311 (peer_active)",
"lightningd/connect_control.c:458 (connectd_msg)",
"lightningd/subd.c:557 (sd_msg_read)",
"lightningd/subd.c:357 (read_fds)",
"ccan/ccan/io/io.c:59 (next_plan)",
"ccan/ccan/io/io.c:407 (do_plan)",
"ccan/ccan/io/io.c:417 (io_ready)",
"ccan/ccan/io/poll.c:453 (io_loop)",
"lightningd/io_loop_with_timers.c:22 (io_loop_with_timers)",
"lightningd/lightningd.c:1182 (main)",
"../csu/libc-start.c:308 (__libc_start_main)"
],
"parents": [
"lightningd/lightningd.c:107:struct lightningd"
]
}
]
}
}
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-07-08 10:58:11 +01:00
|
|
|
/* Since we're detaching from uc, we'll be unreferenced until
|
|
|
|
|
* our imminent exit (as will our parent, openingd->conn). */
|
|
|
|
|
notleak(openingd);
|
|
|
|
|
/* openingd->conn is set to NULL temporarily for this call, so: */
|
|
|
|
|
notleak(tal_parent(openingd));
|
|
|
|
|
|
2022-03-22 20:26:29 +00:00
|
|
|
if (!fromwire_openingd_failed(msg, msg, &desc)) {
|
2020-10-17 01:05:56 +01:00
|
|
|
log_broken(uc->log,
|
2022-03-22 20:26:29 +00:00
|
|
|
"bad OPENINGD_FAILED %s",
|
2020-10-17 01:05:56 +01:00
|
|
|
tal_hex(tmpctx, msg));
|
2022-03-22 20:26:29 +00:00
|
|
|
if (uc->fc)
|
|
|
|
|
was_pending(command_fail(uc->fc->cmd, LIGHTNINGD,
|
|
|
|
|
"bad OPENINGD_FAILED %s",
|
|
|
|
|
tal_hex(uc->fc->cmd, msg)));
|
2020-10-17 01:05:56 +01:00
|
|
|
tal_free(uc);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-22 20:26:29 +00:00
|
|
|
/* Noop if we're not funder. */
|
2020-10-17 01:05:56 +01:00
|
|
|
opening_funder_failed_cancel_commands(uc, desc);
|
2022-03-22 23:01:36 +00:00
|
|
|
/* Detaches from ->peer */
|
|
|
|
|
tal_free(uc);
|
2020-10-17 01:05:56 +01:00
|
|
|
}
|
2018-08-09 01:25:29 +01:00
|
|
|
|
2019-05-20 23:45:20 +01:00
|
|
|
struct openchannel_hook_payload {
|
|
|
|
|
struct subd *openingd;
|
2020-10-08 09:01:09 +01:00
|
|
|
struct uncommitted_channel* uc;
|
2019-05-20 23:45:20 +01:00
|
|
|
struct amount_sat funding_satoshis;
|
|
|
|
|
struct amount_msat push_msat;
|
|
|
|
|
struct amount_sat dust_limit_satoshis;
|
|
|
|
|
struct amount_msat max_htlc_value_in_flight_msat;
|
|
|
|
|
struct amount_sat channel_reserve_satoshis;
|
|
|
|
|
struct amount_msat htlc_minimum_msat;
|
|
|
|
|
u32 feerate_per_kw;
|
|
|
|
|
u16 to_self_delay;
|
|
|
|
|
u16 max_accepted_htlcs;
|
|
|
|
|
u8 channel_flags;
|
|
|
|
|
u8 *shutdown_scriptpubkey;
|
2020-08-20 16:39:36 +01:00
|
|
|
const u8 *our_upfront_shutdown_script;
|
|
|
|
|
char *errmsg;
|
2019-05-20 23:45:20 +01:00
|
|
|
};
|
|
|
|
|
|
2021-06-02 16:33:23 +01:00
|
|
|
static void openchannel_hook_serialize(struct openchannel_hook_payload *payload,
|
|
|
|
|
struct json_stream *stream,
|
|
|
|
|
struct plugin *plugin)
|
2019-05-20 23:45:20 +01:00
|
|
|
{
|
|
|
|
|
struct uncommitted_channel *uc = payload->openingd->channel;
|
|
|
|
|
json_object_start(stream, "openchannel");
|
|
|
|
|
json_add_node_id(stream, "id", &uc->peer->id);
|
2022-06-19 08:16:11 +01:00
|
|
|
json_add_amount_sats_deprecated(stream, "funding_satoshis", "funding_msat",
|
|
|
|
|
payload->funding_satoshis);
|
2019-05-20 23:45:20 +01:00
|
|
|
json_add_amount_msat_only(stream, "push_msat", payload->push_msat);
|
2022-06-19 08:16:11 +01:00
|
|
|
json_add_amount_sats_deprecated(stream, "dust_limit_satoshis", "dust_limit_msat",
|
|
|
|
|
payload->dust_limit_satoshis);
|
2019-05-20 23:45:20 +01:00
|
|
|
json_add_amount_msat_only(stream, "max_htlc_value_in_flight_msat",
|
|
|
|
|
payload->max_htlc_value_in_flight_msat);
|
2022-06-19 08:16:11 +01:00
|
|
|
json_add_amount_sats_deprecated(stream, "channel_reserve_satoshis", "channel_reserve_msat",
|
2019-05-20 23:45:20 +01:00
|
|
|
payload->channel_reserve_satoshis);
|
|
|
|
|
json_add_amount_msat_only(stream, "htlc_minimum_msat",
|
|
|
|
|
payload->htlc_minimum_msat);
|
|
|
|
|
json_add_num(stream, "feerate_per_kw", payload->feerate_per_kw);
|
|
|
|
|
json_add_num(stream, "to_self_delay", payload->to_self_delay);
|
|
|
|
|
json_add_num(stream, "max_accepted_htlcs", payload->max_accepted_htlcs);
|
|
|
|
|
json_add_num(stream, "channel_flags", payload->channel_flags);
|
|
|
|
|
if (tal_count(payload->shutdown_scriptpubkey) != 0)
|
2019-06-05 06:29:01 +01:00
|
|
|
json_add_hex_talarr(stream, "shutdown_scriptpubkey",
|
|
|
|
|
payload->shutdown_scriptpubkey);
|
2019-05-20 23:45:20 +01:00
|
|
|
json_object_end(stream); /* .openchannel */
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* openingd dies? Remove openingd ptr from payload */
|
|
|
|
|
static void openchannel_payload_remove_openingd(struct subd *openingd,
|
|
|
|
|
struct openchannel_hook_payload *payload)
|
|
|
|
|
{
|
|
|
|
|
assert(payload->openingd == openingd);
|
|
|
|
|
payload->openingd = NULL;
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-20 16:39:36 +01:00
|
|
|
static void
|
|
|
|
|
openchannel_hook_final(struct openchannel_hook_payload *payload STEALS)
|
2019-05-20 23:45:20 +01:00
|
|
|
{
|
|
|
|
|
struct subd *openingd = payload->openingd;
|
2020-08-20 16:39:36 +01:00
|
|
|
const u8 *our_upfront_shutdown_script = payload->our_upfront_shutdown_script;
|
|
|
|
|
const char *errmsg = payload->errmsg;
|
2020-10-08 09:01:09 +01:00
|
|
|
struct uncommitted_channel* uc = payload->uc;
|
2021-11-04 17:48:43 +00:00
|
|
|
u32 *upfront_shutdown_script_wallet_index;
|
2019-05-20 23:45:20 +01:00
|
|
|
|
|
|
|
|
/* We want to free this, whatever happens. */
|
|
|
|
|
tal_steal(tmpctx, payload);
|
|
|
|
|
|
|
|
|
|
/* If openingd went away, don't send it anything! */
|
|
|
|
|
if (!openingd)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
tal_del_destructor2(openingd, openchannel_payload_remove_openingd, payload);
|
|
|
|
|
|
2020-10-08 09:01:09 +01:00
|
|
|
if (!errmsg) {
|
|
|
|
|
/* Plugins accepted the offer, cancel any of our
|
|
|
|
|
* funder-side commands. */
|
|
|
|
|
opening_funder_failed_cancel_commands(uc,
|
|
|
|
|
"Have in-progress "
|
|
|
|
|
"`open_channel` from "
|
|
|
|
|
"peer");
|
|
|
|
|
uc->got_offer = true;
|
|
|
|
|
}
|
|
|
|
|
|
2021-11-04 17:48:43 +00:00
|
|
|
/* Determine the wallet index for our_upfront_shutdown_script,
|
|
|
|
|
* NULL if not found. */
|
|
|
|
|
u32 found_wallet_index;
|
|
|
|
|
bool is_p2sh;
|
|
|
|
|
if (wallet_can_spend(payload->openingd->ld->wallet,
|
|
|
|
|
our_upfront_shutdown_script,
|
|
|
|
|
&found_wallet_index,
|
|
|
|
|
&is_p2sh)) {
|
|
|
|
|
upfront_shutdown_script_wallet_index = tal(tmpctx, u32);
|
|
|
|
|
*upfront_shutdown_script_wallet_index = found_wallet_index;
|
|
|
|
|
} else
|
|
|
|
|
upfront_shutdown_script_wallet_index = NULL;
|
|
|
|
|
|
2019-05-20 23:45:20 +01:00
|
|
|
subd_send_msg(openingd,
|
2020-08-25 03:12:18 +01:00
|
|
|
take(towire_openingd_got_offer_reply(NULL, errmsg,
|
2021-11-04 17:48:43 +00:00
|
|
|
our_upfront_shutdown_script,
|
|
|
|
|
upfront_shutdown_script_wallet_index)));
|
2019-05-20 23:45:20 +01:00
|
|
|
}
|
|
|
|
|
|
2020-08-20 16:39:36 +01:00
|
|
|
static bool
|
|
|
|
|
openchannel_hook_deserialize(struct openchannel_hook_payload *payload,
|
|
|
|
|
const char *buffer,
|
|
|
|
|
const jsmntok_t *toks)
|
|
|
|
|
{
|
|
|
|
|
struct subd *openingd = payload->openingd;
|
|
|
|
|
|
|
|
|
|
/* already rejected by prior plugin hook in the chain */
|
|
|
|
|
if (payload->errmsg != NULL)
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
if (!toks || !buffer)
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
|
|
const jsmntok_t *t_result = json_get_member(buffer, toks, "result");
|
|
|
|
|
const jsmntok_t *t_errmsg = json_get_member(buffer, toks, "error_message");
|
|
|
|
|
const jsmntok_t *t_closeto = json_get_member(buffer, toks, "close_to");
|
2022-05-20 14:43:56 +01:00
|
|
|
const jsmntok_t *t_mindepth = json_get_member(buffer, toks, "mindepth");
|
2020-08-20 16:39:36 +01:00
|
|
|
|
|
|
|
|
if (!t_result)
|
|
|
|
|
fatal("Plugin returned an invalid response to the"
|
|
|
|
|
" openchannel hook: %.*s",
|
|
|
|
|
toks[0].end - toks[0].start, buffer + toks[0].start);
|
|
|
|
|
|
|
|
|
|
/* reject */
|
|
|
|
|
if (json_tok_streq(buffer, t_result, "reject")) {
|
|
|
|
|
payload->errmsg = "";
|
|
|
|
|
if (t_errmsg)
|
|
|
|
|
payload->errmsg = json_strdup(payload, buffer, t_errmsg);
|
|
|
|
|
log_debug(openingd->ld->log,
|
2021-01-17 12:48:36 +00:00
|
|
|
"openchannel hook rejects and says '%s'",
|
2020-08-20 16:39:36 +01:00
|
|
|
payload->errmsg);
|
|
|
|
|
if (t_closeto)
|
|
|
|
|
fatal("Plugin rejected openchannel but also set close_to");
|
|
|
|
|
openchannel_hook_final(payload);
|
|
|
|
|
return false;
|
|
|
|
|
} else if (!json_tok_streq(buffer, t_result, "continue")) {
|
|
|
|
|
fatal("Plugin returned an invalid result for the "
|
|
|
|
|
"openchannel hook: %.*s",
|
|
|
|
|
t_result->end - t_result->start, buffer + t_result->start);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Check for a valid 'close_to' address passed back */
|
|
|
|
|
if (t_closeto) {
|
|
|
|
|
/* First plugin can set close_to. Log others. */
|
|
|
|
|
if (payload->our_upfront_shutdown_script != NULL) {
|
2020-09-22 11:00:10 +01:00
|
|
|
log_broken(openingd->ld->log,
|
2021-01-17 12:48:36 +00:00
|
|
|
"openchannel hook close_to address was"
|
2020-09-22 11:00:10 +01:00
|
|
|
" already set by other plugin. Ignoring!");
|
2020-08-20 16:39:36 +01:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
switch (json_to_address_scriptpubkey(tmpctx, chainparams,
|
|
|
|
|
buffer, t_closeto,
|
|
|
|
|
&payload->our_upfront_shutdown_script)) {
|
|
|
|
|
case ADDRESS_PARSE_UNRECOGNIZED:
|
|
|
|
|
fatal("Plugin returned an invalid response to"
|
|
|
|
|
" the openchannel.close_to hook: %.*s",
|
|
|
|
|
t_closeto->end - t_closeto->start,
|
|
|
|
|
buffer + t_closeto->start);
|
|
|
|
|
case ADDRESS_PARSE_WRONG_NETWORK:
|
|
|
|
|
fatal("Plugin returned invalid response to the"
|
|
|
|
|
" openchannel.close_to hook: address %s is"
|
|
|
|
|
" not on network %s",
|
|
|
|
|
tal_hex(NULL, payload->our_upfront_shutdown_script),
|
|
|
|
|
chainparams->network_name);
|
|
|
|
|
case ADDRESS_PARSE_SUCCESS:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2022-05-20 14:43:56 +01:00
|
|
|
|
|
|
|
|
if (t_mindepth != NULL) {
|
|
|
|
|
json_to_u32(buffer, t_mindepth, &payload->uc->minimum_depth);
|
|
|
|
|
log_debug(
|
|
|
|
|
openingd->ld->log,
|
|
|
|
|
"Setting mindepth=%d for this channel as requested by "
|
|
|
|
|
"the openchannel hook",
|
|
|
|
|
payload->uc->minimum_depth);
|
|
|
|
|
}
|
|
|
|
|
|
2020-08-20 16:39:36 +01:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
REGISTER_PLUGIN_HOOK(openchannel,
|
|
|
|
|
openchannel_hook_deserialize,
|
|
|
|
|
openchannel_hook_final,
|
|
|
|
|
openchannel_hook_serialize,
|
|
|
|
|
struct openchannel_hook_payload *);
|
2019-05-20 23:45:20 +01:00
|
|
|
|
2019-05-20 06:05:24 +01:00
|
|
|
static void opening_got_offer(struct subd *openingd,
|
|
|
|
|
const u8 *msg,
|
|
|
|
|
struct uncommitted_channel *uc)
|
|
|
|
|
{
|
2019-05-20 23:45:20 +01:00
|
|
|
struct openchannel_hook_payload *payload;
|
2019-05-20 06:05:24 +01:00
|
|
|
|
2020-04-15 11:20:41 +01:00
|
|
|
payload = tal(openingd, struct openchannel_hook_payload);
|
2019-05-20 23:45:20 +01:00
|
|
|
payload->openingd = openingd;
|
2020-10-08 09:01:09 +01:00
|
|
|
payload->uc = uc;
|
2020-08-20 16:39:36 +01:00
|
|
|
payload->our_upfront_shutdown_script = NULL;
|
|
|
|
|
payload->errmsg = NULL;
|
2020-08-25 03:12:18 +01:00
|
|
|
if (!fromwire_openingd_got_offer(payload, msg,
|
2019-05-20 23:45:20 +01:00
|
|
|
&payload->funding_satoshis,
|
|
|
|
|
&payload->push_msat,
|
|
|
|
|
&payload->dust_limit_satoshis,
|
|
|
|
|
&payload->max_htlc_value_in_flight_msat,
|
|
|
|
|
&payload->channel_reserve_satoshis,
|
|
|
|
|
&payload->htlc_minimum_msat,
|
|
|
|
|
&payload->feerate_per_kw,
|
|
|
|
|
&payload->to_self_delay,
|
|
|
|
|
&payload->max_accepted_htlcs,
|
|
|
|
|
&payload->channel_flags,
|
|
|
|
|
&payload->shutdown_scriptpubkey)) {
|
|
|
|
|
log_broken(openingd->log, "Malformed opening_got_offer %s",
|
|
|
|
|
tal_hex(tmpctx, msg));
|
|
|
|
|
tal_free(openingd);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
tal_add_destructor2(openingd, openchannel_payload_remove_openingd, payload);
|
2020-04-15 11:20:41 +01:00
|
|
|
plugin_hook_call_openchannel(openingd->ld, payload);
|
2019-05-20 06:05:24 +01:00
|
|
|
}
|
|
|
|
|
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
static unsigned int openingd_msg(struct subd *openingd,
|
|
|
|
|
const u8 *msg, const int *fds)
|
|
|
|
|
{
|
2020-08-25 03:12:18 +01:00
|
|
|
enum openingd_wire t = fromwire_peektype(msg);
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
struct uncommitted_channel *uc = openingd->channel;
|
|
|
|
|
|
|
|
|
|
switch (t) {
|
2020-08-25 03:12:18 +01:00
|
|
|
case WIRE_OPENINGD_FUNDER_REPLY:
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
if (!uc->fc) {
|
|
|
|
|
log_broken(openingd->log, "Unexpected FUNDER_REPLY %s",
|
|
|
|
|
tal_hex(tmpctx, msg));
|
|
|
|
|
tal_free(openingd);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2022-01-29 03:33:05 +00:00
|
|
|
if (tal_count(fds) != 1)
|
|
|
|
|
return 1;
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
opening_funder_finished(openingd, msg, fds, uc->fc);
|
|
|
|
|
return 0;
|
2020-08-25 03:12:18 +01:00
|
|
|
case WIRE_OPENINGD_FUNDER_START_REPLY:
|
2019-05-22 00:51:52 +01:00
|
|
|
if (!uc->fc) {
|
|
|
|
|
log_broken(openingd->log, "Unexpected FUNDER_START_REPLY %s",
|
|
|
|
|
tal_hex(tmpctx, msg));
|
|
|
|
|
tal_free(openingd);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2019-05-23 00:25:22 +01:00
|
|
|
opening_funder_start_replied(openingd, msg, fds, uc->fc);
|
2019-05-22 00:51:52 +01:00
|
|
|
return 0;
|
2022-03-22 20:26:29 +00:00
|
|
|
case WIRE_OPENINGD_FAILED:
|
|
|
|
|
openingd_failed(openingd, msg, uc);
|
2018-08-09 01:25:29 +01:00
|
|
|
return 0;
|
|
|
|
|
|
2020-08-25 03:12:18 +01:00
|
|
|
case WIRE_OPENINGD_FUNDEE:
|
2022-01-29 03:33:05 +00:00
|
|
|
if (tal_count(fds) != 1)
|
|
|
|
|
return 1;
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
opening_fundee_finished(openingd, msg, fds, uc);
|
|
|
|
|
return 0;
|
|
|
|
|
|
2020-08-25 03:12:18 +01:00
|
|
|
case WIRE_OPENINGD_GOT_OFFER:
|
2019-05-20 06:05:24 +01:00
|
|
|
opening_got_offer(openingd, msg, uc);
|
|
|
|
|
return 0;
|
|
|
|
|
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
/* We send these! */
|
2020-08-25 03:12:18 +01:00
|
|
|
case WIRE_OPENINGD_INIT:
|
|
|
|
|
case WIRE_OPENINGD_FUNDER_START:
|
|
|
|
|
case WIRE_OPENINGD_FUNDER_COMPLETE:
|
|
|
|
|
case WIRE_OPENINGD_FUNDER_CANCEL:
|
|
|
|
|
case WIRE_OPENINGD_GOT_OFFER_REPLY:
|
|
|
|
|
case WIRE_OPENINGD_DEV_MEMLEAK:
|
2018-11-22 02:17:29 +00:00
|
|
|
/* Replies never get here */
|
2020-08-25 03:12:18 +01:00
|
|
|
case WIRE_OPENINGD_DEV_MEMLEAK_REPLY:
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
break;
|
|
|
|
|
}
|
2019-11-28 18:07:52 +00:00
|
|
|
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
log_broken(openingd->log, "Unexpected msg %s: %s",
|
2020-08-25 03:12:18 +01:00
|
|
|
openingd_wire_name(t), tal_hex(tmpctx, msg));
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
tal_free(openingd);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2022-03-22 20:27:29 +00:00
|
|
|
bool peer_start_openingd(struct peer *peer, struct peer_fd *peer_fd)
|
2018-02-20 20:59:04 +00:00
|
|
|
{
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
int hsmfd;
|
2018-05-17 05:46:22 +01:00
|
|
|
u32 max_to_self_delay;
|
2019-02-21 03:45:54 +00:00
|
|
|
struct amount_msat min_effective_htlc_capacity;
|
2018-02-20 20:59:04 +00:00
|
|
|
struct uncommitted_channel *uc;
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
const u8 *msg;
|
2018-02-20 20:59:04 +00:00
|
|
|
|
2022-03-22 20:27:29 +00:00
|
|
|
assert(peer->uncommitted_channel);
|
|
|
|
|
uc = peer->uncommitted_channel;
|
|
|
|
|
assert(!uc->open_daemon);
|
2018-02-20 20:59:04 +00:00
|
|
|
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
hsmfd = hsm_get_client_fd(peer->ld, &uc->peer->id, uc->dbid,
|
2018-07-23 03:23:03 +01:00
|
|
|
HSM_CAP_COMMITMENT_POINT
|
|
|
|
|
| HSM_CAP_SIGN_REMOTE_TX);
|
|
|
|
|
|
2022-03-29 00:49:23 +01:00
|
|
|
uc->open_daemon = new_channel_subd(peer, peer->ld,
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
"lightning_openingd",
|
2021-01-20 01:51:15 +00:00
|
|
|
uc, &peer->id, uc->log,
|
2020-08-25 03:12:18 +01:00
|
|
|
true, openingd_wire_name,
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
openingd_msg,
|
2020-09-09 08:20:53 +01:00
|
|
|
opend_channel_errmsg,
|
|
|
|
|
opend_channel_set_billboard,
|
2022-01-11 01:13:59 +00:00
|
|
|
take(&peer_fd->fd),
|
2018-07-23 03:23:03 +01:00
|
|
|
take(&hsmfd), NULL);
|
2020-09-09 08:20:53 +01:00
|
|
|
if (!uc->open_daemon) {
|
2020-03-25 04:26:44 +00:00
|
|
|
uncommitted_channel_disconnect(uc, LOG_BROKEN,
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
tal_fmt(tmpctx,
|
|
|
|
|
"Running lightning_openingd: %s",
|
|
|
|
|
strerror(errno)));
|
2020-03-25 04:15:16 +00:00
|
|
|
tal_free(uc);
|
2022-03-22 20:27:29 +00:00
|
|
|
return false;
|
2018-02-20 20:59:04 +00:00
|
|
|
}
|
|
|
|
|
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
channel_config(peer->ld, &uc->our_config,
|
|
|
|
|
&max_to_self_delay,
|
2019-02-21 03:45:54 +00:00
|
|
|
&min_effective_htlc_capacity);
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
|
2018-02-20 20:59:04 +00:00
|
|
|
|
2020-08-25 03:12:18 +01:00
|
|
|
msg = towire_openingd_init(NULL,
|
2019-09-25 21:38:45 +01:00
|
|
|
chainparams,
|
2020-04-03 01:03:59 +01:00
|
|
|
peer->ld->our_features,
|
2021-09-09 03:37:51 +01:00
|
|
|
peer->their_features,
|
2018-02-20 20:59:04 +00:00
|
|
|
&uc->our_config,
|
|
|
|
|
max_to_self_delay,
|
2019-02-21 03:45:55 +00:00
|
|
|
min_effective_htlc_capacity,
|
2022-01-08 13:29:29 +00:00
|
|
|
&uc->local_basepoints,
|
openingd: take peer before we're opening, wait for explicit funding msg.
Prior to this, lightningd would hand uninteresting peers back to connectd,
which would then return it to lightningd if it sent a non-gossip msg,
or if lightningd asked it to release the peer.
Now connectd hands the peer to lightningd once we've done the init
handshake, which hands it off to openingd.
This is a deep structural change, so we do the minimum here and cleanup
in the following patches.
Lightningd:
1. Remove peer_nongossip handling from connect_control and peer_control.
2. Remove list of outstanding fundchannel command; it was only needed to
find the race between us asking connectd to release the peer and it
reconnecting.
3. We can no longer tell if the remote end has started trying to fund a
channel (until it has succeeded): it's very transitory anyway so not
worth fixing.
4. We now always have a struct peer, and allocate an uncommitted_channel
for it, though it may never be used if neither end funds a channel.
5. We start funding on messages for openingd: we can get a funder_reply
or a fundee, or an error in response to our request to fund a channel.
so we handle all of them.
6. A new peer_start_openingd() is called after connectd hands us a peer.
7. json_fund_channel just looks through local peers; there are none
hidden in connectd any more.
8. We sometimes start a new openingd just to send an error message.
Openingd:
1. We always have information we need to accept them funding a channel (in
the init message).
2. We have to listen for three fds: peer, gossip and master, so we opencode
the poll.
3. We have an explicit message to start trying to fund a channel.
4. We can be told to send a message in our init message.
Testing:
1. We don't handle some things gracefully yet, so two tests are disabled.
2. 'hand_back_peer .*: now local again' from connectd is no longer a message,
openingd says 'Handed peer, entering loop' once its managing it.
3. peer['state'] used to be set to 'GOSSIPING' (otherwise this field doesn't
exist; 'state' is now per-channel. It doesn't exist at all now.
4. Some tests now need to turn on IO logging in openingd, not connectd.
5. There's a gap between connecting on one node and having connectd on
the peer hand over the connection to openingd. Our tests sometimes
checked getpeers() on the peer, and didn't see anything, so line_graph
needed updating.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-08 15:10:58 +01:00
|
|
|
&uc->local_funding_pubkey,
|
|
|
|
|
uc->minimum_depth,
|
2018-08-23 00:27:25 +01:00
|
|
|
feerate_min(peer->ld, NULL),
|
|
|
|
|
feerate_max(peer->ld, NULL),
|
2022-01-08 13:29:29 +00:00
|
|
|
IFDEV(peer->ld->dev_force_tmp_channel_id, NULL));
|
2020-09-09 08:20:53 +01:00
|
|
|
subd_send_msg(uc->open_daemon, take(msg));
|
2022-03-22 20:27:29 +00:00
|
|
|
return true;
|
2018-04-23 11:08:01 +01:00
|
|
|
}
|
|
|
|
|
|
2021-03-15 03:39:44 +00:00
|
|
|
static struct command_result *json_fundchannel_complete(struct command *cmd,
|
|
|
|
|
const char *buffer,
|
|
|
|
|
const jsmntok_t *obj UNNEEDED,
|
|
|
|
|
const jsmntok_t *params)
|
2019-05-25 01:40:00 +01:00
|
|
|
{
|
|
|
|
|
u8 *msg;
|
|
|
|
|
struct node_id *id;
|
|
|
|
|
struct bitcoin_txid *funding_txid;
|
|
|
|
|
struct peer *peer;
|
2021-03-15 04:27:56 +00:00
|
|
|
struct wally_psbt *funding_psbt;
|
|
|
|
|
u32 *funding_txout_num = NULL;
|
|
|
|
|
struct funding_channel *fc;
|
2021-11-10 00:27:41 +00:00
|
|
|
|
|
|
|
|
if (!param(cmd, buffer, params,
|
|
|
|
|
p_req("id", param_node_id, &id),
|
|
|
|
|
p_req("psbt", param_psbt, &funding_psbt),
|
|
|
|
|
NULL))
|
|
|
|
|
return command_param_failed();
|
2019-05-31 22:37:05 +01:00
|
|
|
|
2019-05-25 01:40:00 +01:00
|
|
|
peer = peer_by_id(cmd->ld, id);
|
|
|
|
|
if (!peer) {
|
2020-01-04 20:10:04 +00:00
|
|
|
return command_fail(cmd, FUNDING_UNKNOWN_PEER, "Unknown peer");
|
2019-05-25 01:40:00 +01:00
|
|
|
}
|
|
|
|
|
|
2022-07-16 05:49:31 +01:00
|
|
|
if (peer->connected != PEER_CONNECTED)
|
2020-01-04 20:10:04 +00:00
|
|
|
return command_fail(cmd, FUNDING_PEER_NOT_CONNECTED,
|
2022-07-16 05:49:31 +01:00
|
|
|
"Peer %s",
|
|
|
|
|
peer->connected == PEER_DISCONNECTED
|
|
|
|
|
? "not connected" : "still connecting");
|
2019-05-25 01:40:00 +01:00
|
|
|
|
2022-03-22 20:27:29 +00:00
|
|
|
if (!peer->uncommitted_channel
|
|
|
|
|
|| !peer->uncommitted_channel->fc
|
|
|
|
|
|| !peer->uncommitted_channel->fc->inflight)
|
2019-05-25 01:40:00 +01:00
|
|
|
return command_fail(cmd, LIGHTNINGD, "No channel funding in progress.");
|
2022-03-22 20:27:29 +00:00
|
|
|
|
2019-06-12 07:23:24 +01:00
|
|
|
if (peer->uncommitted_channel->fc->cmd)
|
|
|
|
|
return command_fail(cmd, LIGHTNINGD, "Channel funding in progress.");
|
2019-05-25 01:40:00 +01:00
|
|
|
|
2021-03-15 04:27:56 +00:00
|
|
|
fc = peer->uncommitted_channel->fc;
|
|
|
|
|
|
2021-11-10 00:27:41 +00:00
|
|
|
/* Figure out the correct output, and perform sanity checks. */
|
|
|
|
|
for (size_t i = 0; i < funding_psbt->tx->num_outputs; i++) {
|
|
|
|
|
if (memeq(funding_psbt->tx->outputs[i].script,
|
|
|
|
|
funding_psbt->tx->outputs[i].script_len,
|
|
|
|
|
fc->funding_scriptpubkey,
|
|
|
|
|
tal_bytelen(fc->funding_scriptpubkey))) {
|
|
|
|
|
if (funding_txout_num)
|
|
|
|
|
return command_fail(cmd, FUNDING_PSBT_INVALID,
|
|
|
|
|
"Two outputs to open channel");
|
|
|
|
|
funding_txout_num = tal(cmd, u32);
|
|
|
|
|
*funding_txout_num = i;
|
2021-03-15 04:27:56 +00:00
|
|
|
}
|
|
|
|
|
}
|
2021-11-10 00:27:41 +00:00
|
|
|
if (!funding_txout_num)
|
|
|
|
|
return command_fail(cmd, FUNDING_PSBT_INVALID,
|
|
|
|
|
"No output to open channel");
|
|
|
|
|
|
|
|
|
|
/* Can't really check amounts for elements. */
|
|
|
|
|
if (!chainparams->is_elements
|
|
|
|
|
&& !amount_sat_eq(amount_sat(funding_psbt->tx->outputs
|
|
|
|
|
[*funding_txout_num].satoshi),
|
|
|
|
|
fc->funding_sats))
|
|
|
|
|
return command_fail(cmd, FUNDING_PSBT_INVALID,
|
|
|
|
|
"Output to open channel is %"PRIu64"sat,"
|
|
|
|
|
" should be %s",
|
|
|
|
|
funding_psbt->tx->outputs
|
|
|
|
|
[*funding_txout_num].satoshi,
|
|
|
|
|
type_to_string(tmpctx, struct amount_sat,
|
|
|
|
|
&fc->funding_sats));
|
|
|
|
|
|
|
|
|
|
funding_txid = tal(cmd, struct bitcoin_txid);
|
|
|
|
|
psbt_txid(NULL, funding_psbt, funding_txid, NULL);
|
2021-03-15 04:27:56 +00:00
|
|
|
|
|
|
|
|
/* Fun fact: our wire protocol only allows 16 bits for outnum.
|
|
|
|
|
* That is reflected in our encoding scheme for short_channel_id. */
|
|
|
|
|
if (*funding_txout_num > UINT16_MAX)
|
|
|
|
|
return command_fail(cmd, JSONRPC2_INVALID_PARAMS,
|
|
|
|
|
"Invalid parameter: funding tx vout too large %u",
|
|
|
|
|
*funding_txout_num);
|
|
|
|
|
|
2019-06-12 07:23:24 +01:00
|
|
|
/* Set the cmd to this new cmd */
|
2019-05-31 22:46:04 +01:00
|
|
|
peer->uncommitted_channel->fc->cmd = cmd;
|
2020-08-25 03:12:18 +01:00
|
|
|
msg = towire_openingd_funder_complete(NULL,
|
2021-09-10 03:14:16 +01:00
|
|
|
funding_txid,
|
|
|
|
|
*funding_txout_num,
|
|
|
|
|
peer->uncommitted_channel->fc->channel_type);
|
2020-09-09 08:20:53 +01:00
|
|
|
subd_send_msg(peer->uncommitted_channel->open_daemon, take(msg));
|
2019-05-25 01:40:00 +01:00
|
|
|
return command_still_pending(cmd);
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-31 22:57:04 +01:00
|
|
|
/**
|
2021-03-15 03:39:44 +00:00
|
|
|
* json_fundchannel_cancel - Entrypoint for cancelling a channel which funding isn't broadcast
|
2019-05-31 22:57:04 +01:00
|
|
|
*/
|
2021-03-15 03:39:44 +00:00
|
|
|
static struct command_result *json_fundchannel_cancel(struct command *cmd,
|
|
|
|
|
const char *buffer,
|
|
|
|
|
const jsmntok_t *obj UNNEEDED,
|
|
|
|
|
const jsmntok_t *params)
|
2019-05-31 22:57:04 +01:00
|
|
|
{
|
|
|
|
|
|
|
|
|
|
struct node_id *id;
|
|
|
|
|
struct peer *peer;
|
|
|
|
|
u8 *msg;
|
|
|
|
|
|
|
|
|
|
if (!param(cmd, buffer, params,
|
|
|
|
|
p_req("id", param_node_id, &id),
|
|
|
|
|
NULL))
|
|
|
|
|
return command_param_failed();
|
|
|
|
|
|
|
|
|
|
peer = peer_by_id(cmd->ld, id);
|
|
|
|
|
if (!peer) {
|
2020-01-04 20:10:04 +00:00
|
|
|
return command_fail(cmd, FUNDING_UNKNOWN_PEER, "Unknown peer");
|
2019-05-31 22:57:04 +01:00
|
|
|
}
|
|
|
|
|
|
2019-08-23 22:34:52 +01:00
|
|
|
if (peer->uncommitted_channel) {
|
2020-01-05 15:52:34 +00:00
|
|
|
if (!peer->uncommitted_channel->fc || !peer->uncommitted_channel->fc->inflight)
|
2020-06-24 05:34:26 +01:00
|
|
|
return command_fail(cmd, FUNDING_NOTHING_TO_CANCEL,
|
|
|
|
|
"No channel funding in progress.");
|
2019-05-31 22:57:04 +01:00
|
|
|
|
2019-08-23 22:34:52 +01:00
|
|
|
/* Make sure this gets notified if we succeed or cancel */
|
|
|
|
|
tal_arr_expand(&peer->uncommitted_channel->fc->cancels, cmd);
|
2020-08-25 03:12:18 +01:00
|
|
|
msg = towire_openingd_funder_cancel(NULL);
|
2020-09-09 08:20:53 +01:00
|
|
|
subd_send_msg(peer->uncommitted_channel->open_daemon, take(msg));
|
2019-08-23 22:34:52 +01:00
|
|
|
return command_still_pending(cmd);
|
|
|
|
|
}
|
2019-05-31 22:57:04 +01:00
|
|
|
|
2022-03-22 20:27:29 +00:00
|
|
|
log_debug(cmd->ld->log, "fundchannel_cancel no uncommitted_channel!");
|
|
|
|
|
|
2020-06-24 05:34:26 +01:00
|
|
|
/* Handle `fundchannel_cancel` after `fundchannel_complete`. */
|
|
|
|
|
return cancel_channel_before_broadcast(cmd, peer);
|
2019-05-31 22:57:04 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2021-03-15 03:39:44 +00:00
|
|
|
* json_fundchannel_start - Entrypoint for funding a channel
|
2019-05-31 22:57:04 +01:00
|
|
|
*/
|
2021-03-15 03:39:44 +00:00
|
|
|
static struct command_result *json_fundchannel_start(struct command *cmd,
|
|
|
|
|
const char *buffer,
|
|
|
|
|
const jsmntok_t *obj UNNEEDED,
|
|
|
|
|
const jsmntok_t *params)
|
2019-05-22 00:51:52 +01:00
|
|
|
{
|
|
|
|
|
struct funding_channel * fc = tal(cmd, struct funding_channel);
|
|
|
|
|
struct node_id *id;
|
|
|
|
|
struct peer *peer;
|
|
|
|
|
bool *announce_channel;
|
2022-05-20 10:45:26 +01:00
|
|
|
u32 *feerate_per_kw, *mindepth;
|
2022-07-18 13:12:18 +01:00
|
|
|
int fds[2];
|
2019-11-23 01:45:51 +00:00
|
|
|
struct amount_sat *amount;
|
2019-12-21 05:53:12 +00:00
|
|
|
struct amount_msat *push_msat;
|
2021-11-04 17:48:43 +00:00
|
|
|
u32 *upfront_shutdown_script_wallet_index;
|
2022-03-22 20:27:30 +00:00
|
|
|
struct channel_id tmp_channel_id;
|
2019-05-22 00:51:52 +01:00
|
|
|
|
|
|
|
|
fc->cmd = cmd;
|
2019-06-13 05:26:51 +01:00
|
|
|
fc->cancels = tal_arr(fc, struct command *, 0);
|
2019-05-22 00:51:52 +01:00
|
|
|
fc->uc = NULL;
|
2019-05-31 22:40:31 +01:00
|
|
|
fc->inflight = false;
|
2021-03-15 03:40:44 +00:00
|
|
|
fc->funding_scriptpubkey = NULL;
|
2019-09-19 19:50:58 +01:00
|
|
|
|
2020-03-25 03:39:34 +00:00
|
|
|
if (!param(fc->cmd, buffer, params,
|
|
|
|
|
p_req("id", param_node_id, &id),
|
|
|
|
|
p_req("amount", param_sat, &amount),
|
|
|
|
|
p_opt("feerate", param_feerate, &feerate_per_kw),
|
|
|
|
|
p_opt_def("announce", param_bool, &announce_channel, true),
|
|
|
|
|
p_opt("close_to", param_bitcoin_address, &fc->our_upfront_shutdown_script),
|
|
|
|
|
p_opt("push_msat", param_msat, &push_msat),
|
2022-05-20 10:45:26 +01:00
|
|
|
p_opt_def("mindepth", param_u32, &mindepth, cmd->ld->config.anchor_confirms),
|
2020-03-25 03:39:34 +00:00
|
|
|
NULL))
|
|
|
|
|
return command_param_failed();
|
2019-05-22 00:51:52 +01:00
|
|
|
|
2019-12-21 05:53:12 +00:00
|
|
|
if (push_msat && amount_msat_greater_sat(*push_msat, *amount))
|
|
|
|
|
return command_fail(cmd, FUND_CANNOT_AFFORD,
|
|
|
|
|
"Requested to push_msat of %s is greater than "
|
|
|
|
|
"available funding amount %s",
|
|
|
|
|
type_to_string(tmpctx, struct amount_msat, push_msat),
|
|
|
|
|
type_to_string(tmpctx, struct amount_sat, amount));
|
|
|
|
|
|
2021-10-13 04:45:36 +01:00
|
|
|
fc->funding_sats = *amount;
|
2019-05-22 00:51:52 +01:00
|
|
|
if (!feerate_per_kw) {
|
|
|
|
|
feerate_per_kw = tal(cmd, u32);
|
|
|
|
|
*feerate_per_kw = opening_feerate(cmd->ld->topology);
|
|
|
|
|
if (!*feerate_per_kw) {
|
|
|
|
|
return command_fail(cmd, LIGHTNINGD,
|
|
|
|
|
"Cannot estimate fees");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (*feerate_per_kw < feerate_floor()) {
|
|
|
|
|
return command_fail(cmd, LIGHTNINGD,
|
|
|
|
|
"Feerate below feerate floor");
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-10 11:48:20 +01:00
|
|
|
if (!topology_synced(cmd->ld->topology)) {
|
|
|
|
|
return command_fail(cmd, FUNDING_STILL_SYNCING_BITCOIN,
|
|
|
|
|
"Still syncing with bitcoin network");
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-22 00:51:52 +01:00
|
|
|
peer = peer_by_id(cmd->ld, id);
|
|
|
|
|
if (!peer) {
|
2020-01-04 20:10:04 +00:00
|
|
|
return command_fail(cmd, FUNDING_UNKNOWN_PEER, "Unknown peer");
|
2019-05-22 00:51:52 +01:00
|
|
|
}
|
|
|
|
|
|
2022-07-16 05:49:31 +01:00
|
|
|
if (peer->connected != PEER_CONNECTED)
|
2022-03-22 20:27:29 +00:00
|
|
|
return command_fail(cmd, FUNDING_PEER_NOT_CONNECTED,
|
2022-07-16 05:49:31 +01:00
|
|
|
"Peer %s",
|
|
|
|
|
peer->connected == PEER_DISCONNECTED
|
|
|
|
|
? "not connected" : "still connecting");
|
2022-03-22 20:27:29 +00:00
|
|
|
|
2022-07-16 05:49:29 +01:00
|
|
|
temporary_channel_id(&tmp_channel_id);
|
|
|
|
|
|
2019-05-22 00:51:52 +01:00
|
|
|
if (!peer->uncommitted_channel) {
|
2021-06-01 20:38:55 +01:00
|
|
|
if (feature_negotiated(cmd->ld->our_features,
|
|
|
|
|
peer->their_features,
|
|
|
|
|
OPT_DUAL_FUND))
|
|
|
|
|
return command_fail(cmd, FUNDING_STATE_INVALID,
|
|
|
|
|
"Peer negotiated"
|
|
|
|
|
" `option_dual_fund`,"
|
|
|
|
|
" must use `openchannel_init` not"
|
|
|
|
|
" `fundchannel_start`.");
|
|
|
|
|
|
2022-03-22 20:27:29 +00:00
|
|
|
log_debug(cmd->ld->log, "fundchannel_start: allocating uncommitted_channel");
|
|
|
|
|
peer->uncommitted_channel = new_uncommitted_channel(peer);
|
|
|
|
|
} else
|
|
|
|
|
log_debug(cmd->ld->log, "fundchannel_start: reusing uncommitted_channel");
|
2019-05-22 00:51:52 +01:00
|
|
|
|
|
|
|
|
if (peer->uncommitted_channel->fc) {
|
|
|
|
|
return command_fail(cmd, LIGHTNINGD, "Already funding channel");
|
|
|
|
|
}
|
|
|
|
|
|
2020-10-08 09:01:09 +01:00
|
|
|
if (peer->uncommitted_channel->got_offer) {
|
|
|
|
|
return command_fail(cmd, LIGHTNINGD,
|
|
|
|
|
"Have in-progress "
|
|
|
|
|
"`open_channel` from "
|
|
|
|
|
"peer");
|
|
|
|
|
}
|
|
|
|
|
|
2022-07-16 05:49:29 +01:00
|
|
|
peer->uncommitted_channel->cid = tmp_channel_id;
|
|
|
|
|
|
2020-04-03 01:03:55 +01:00
|
|
|
/* BOLT #2:
|
|
|
|
|
* - if both nodes advertised `option_support_large_channel`:
|
|
|
|
|
* - MAY set `funding_satoshis` greater than or equal to 2^24 satoshi.
|
|
|
|
|
* - otherwise:
|
|
|
|
|
* - MUST set `funding_satoshis` to less than 2^24 satoshi.
|
|
|
|
|
*/
|
2020-04-03 01:03:59 +01:00
|
|
|
if (!feature_negotiated(cmd->ld->our_features,
|
|
|
|
|
peer->their_features, OPT_LARGE_CHANNELS)
|
2020-04-03 01:03:55 +01:00
|
|
|
&& amount_sat_greater(*amount, chainparams->max_funding))
|
|
|
|
|
return command_fail(cmd, FUND_MAX_EXCEEDED,
|
|
|
|
|
"Amount exceeded %s",
|
|
|
|
|
type_to_string(tmpctx, struct amount_sat,
|
|
|
|
|
&chainparams->max_funding));
|
|
|
|
|
|
2019-12-21 05:53:12 +00:00
|
|
|
fc->push = push_msat ? *push_msat : AMOUNT_MSAT(0);
|
2019-05-22 00:51:52 +01:00
|
|
|
fc->channel_flags = OUR_CHANNEL_FLAGS;
|
|
|
|
|
if (!*announce_channel) {
|
|
|
|
|
fc->channel_flags &= ~CHANNEL_FLAGS_ANNOUNCE_CHANNEL;
|
|
|
|
|
log_info(peer->ld->log, "Will open private channel with node %s",
|
|
|
|
|
type_to_string(fc, struct node_id, id));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
peer->uncommitted_channel->fc = tal_steal(peer->uncommitted_channel, fc);
|
|
|
|
|
fc->uc = peer->uncommitted_channel;
|
|
|
|
|
|
2022-05-20 10:45:26 +01:00
|
|
|
/* BOLT #2:
|
|
|
|
|
*
|
|
|
|
|
* The sender:
|
|
|
|
|
* - SHOULD set `minimum_depth` to a number of blocks it considers
|
|
|
|
|
* reasonable to avoid double-spending of the funding transaction.
|
|
|
|
|
*/
|
|
|
|
|
assert(mindepth != NULL);
|
|
|
|
|
fc->uc->minimum_depth = *mindepth;
|
|
|
|
|
|
2019-10-15 02:08:33 +01:00
|
|
|
/* Needs to be stolen away from cmd */
|
|
|
|
|
if (fc->our_upfront_shutdown_script)
|
|
|
|
|
fc->our_upfront_shutdown_script
|
|
|
|
|
= tal_steal(fc, fc->our_upfront_shutdown_script);
|
|
|
|
|
|
2021-11-04 17:48:43 +00:00
|
|
|
/* Determine the wallet index for our_upfront_shutdown_script,
|
|
|
|
|
* NULL if not found. */
|
|
|
|
|
u32 found_wallet_index;
|
|
|
|
|
bool is_p2sh;
|
|
|
|
|
if (wallet_can_spend(fc->cmd->ld->wallet,
|
|
|
|
|
fc->our_upfront_shutdown_script,
|
|
|
|
|
&found_wallet_index,
|
|
|
|
|
&is_p2sh)) {
|
|
|
|
|
upfront_shutdown_script_wallet_index = tal(tmpctx, u32);
|
|
|
|
|
*upfront_shutdown_script_wallet_index = found_wallet_index;
|
|
|
|
|
} else
|
|
|
|
|
upfront_shutdown_script_wallet_index = NULL;
|
|
|
|
|
|
2022-03-22 20:27:29 +00:00
|
|
|
fc->open_msg
|
|
|
|
|
= towire_openingd_funder_start(fc,
|
2019-05-22 00:51:52 +01:00
|
|
|
*amount,
|
|
|
|
|
fc->push,
|
2019-10-15 02:08:33 +01:00
|
|
|
fc->our_upfront_shutdown_script,
|
2021-11-04 17:48:43 +00:00
|
|
|
upfront_shutdown_script_wallet_index,
|
2019-05-22 00:51:52 +01:00
|
|
|
*feerate_per_kw,
|
2022-03-22 20:27:30 +00:00
|
|
|
&tmp_channel_id,
|
2019-05-22 00:51:52 +01:00
|
|
|
fc->channel_flags);
|
|
|
|
|
|
2022-07-18 13:12:18 +01:00
|
|
|
if (socketpair(AF_LOCAL, SOCK_STREAM, 0, fds) != 0) {
|
|
|
|
|
return command_fail(cmd, FUND_MAX_EXCEEDED,
|
|
|
|
|
"Failed to create socketpair: %s",
|
|
|
|
|
strerror(errno));
|
|
|
|
|
}
|
|
|
|
|
if (!peer_start_openingd(peer, new_peer_fd(cmd, fds[0]))) {
|
|
|
|
|
close(fds[1]);
|
|
|
|
|
/* FIXME: gets completed by failure path above! */
|
|
|
|
|
return command_its_complicated("completed by peer_start_openingd");
|
|
|
|
|
}
|
|
|
|
|
/* Tell it to start funding */
|
|
|
|
|
subd_send_msg(peer->uncommitted_channel->open_daemon, fc->open_msg);
|
|
|
|
|
|
|
|
|
|
/* Tell connectd connect this to this channel id. */
|
2022-03-22 20:27:29 +00:00
|
|
|
subd_send_msg(peer->ld->connectd,
|
2022-07-18 13:12:18 +01:00
|
|
|
take(towire_connectd_peer_connect_subd(NULL,
|
|
|
|
|
&peer->id,
|
2022-07-18 13:12:27 +01:00
|
|
|
peer->connectd_counter,
|
2022-07-18 13:12:18 +01:00
|
|
|
&peer->uncommitted_channel->cid)));
|
|
|
|
|
subd_send_fd(peer->ld->connectd, fds[1]);
|
2019-05-22 00:51:52 +01:00
|
|
|
return command_still_pending(cmd);
|
|
|
|
|
}
|
|
|
|
|
|
2022-06-24 02:14:11 +01:00
|
|
|
static struct channel *stub_chan(struct command *cmd,
|
|
|
|
|
u64 id,
|
|
|
|
|
struct node_id nodeid,
|
|
|
|
|
struct channel_id cid,
|
|
|
|
|
struct bitcoin_outpoint funding,
|
|
|
|
|
struct wireaddr_internal addr,
|
|
|
|
|
struct amount_sat funding_sats,
|
|
|
|
|
struct channel_type *type)
|
|
|
|
|
{
|
|
|
|
|
struct basepoints basepoints;
|
|
|
|
|
struct bitcoin_signature *sig;
|
|
|
|
|
struct channel *channel;
|
|
|
|
|
struct channel_config *our_config;
|
|
|
|
|
struct channel_config *their_config;
|
|
|
|
|
struct channel_info *channel_info;
|
|
|
|
|
struct lightningd *ld;
|
|
|
|
|
struct peer *peer;
|
|
|
|
|
struct pubkey localFundingPubkey;
|
|
|
|
|
struct pubkey pk;
|
|
|
|
|
struct short_channel_id *scid;
|
|
|
|
|
u32 blockht;
|
|
|
|
|
u32 feerate;
|
|
|
|
|
u8 *dummy_sig = tal_hexdata(cmd,
|
|
|
|
|
"30450221009b2e0eef267b94c3899fb0dc73750"
|
|
|
|
|
"12e2cee4c10348a068fe78d1b82b4b1403602207"
|
|
|
|
|
"7c3fad3adac2ddf33f415e45f0daf6658b7a0b09"
|
|
|
|
|
"647de4443938ae2dbafe2b9" "01",
|
|
|
|
|
144);
|
|
|
|
|
|
|
|
|
|
peer = new_peer(cmd->ld,
|
|
|
|
|
0,
|
|
|
|
|
&nodeid,
|
|
|
|
|
&addr,
|
|
|
|
|
false);
|
|
|
|
|
|
|
|
|
|
ld = cmd->ld;
|
|
|
|
|
feerate = FEERATE_FLOOR;
|
|
|
|
|
|
|
|
|
|
sig = tal(cmd, struct bitcoin_signature);
|
|
|
|
|
signature_from_der(dummy_sig,
|
|
|
|
|
tal_bytelen(dummy_sig)
|
|
|
|
|
,sig);
|
|
|
|
|
|
|
|
|
|
if (!pubkey_from_der(tal_hexdata(cmd,
|
|
|
|
|
type_to_string(tmpctx,
|
|
|
|
|
struct node_id,
|
|
|
|
|
&nodeid),
|
|
|
|
|
66),
|
|
|
|
|
33,
|
|
|
|
|
&pk))
|
|
|
|
|
{
|
|
|
|
|
fatal("Invalid node id!");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
get_channel_basepoints(ld,
|
|
|
|
|
&nodeid,
|
|
|
|
|
id,
|
|
|
|
|
&basepoints,
|
|
|
|
|
&localFundingPubkey);
|
|
|
|
|
|
|
|
|
|
channel_info = tal(cmd,
|
|
|
|
|
struct channel_info);
|
|
|
|
|
|
|
|
|
|
our_config = tal(cmd, struct channel_config);
|
|
|
|
|
their_config = tal(cmd, struct channel_config);
|
|
|
|
|
|
|
|
|
|
/* FIXME: Makeake these a pointer, so they could be NULL */
|
|
|
|
|
memset(our_config, 0, sizeof(struct channel_config));
|
|
|
|
|
memset(their_config, 0, sizeof(struct channel_config));
|
|
|
|
|
channel_info->their_config = *their_config;
|
|
|
|
|
channel_info->theirbase = basepoints;
|
|
|
|
|
channel_info->remote_fundingkey = pk;
|
|
|
|
|
channel_info->remote_per_commit = pk;
|
|
|
|
|
channel_info->old_remote_per_commit = pk;
|
|
|
|
|
|
|
|
|
|
blockht = 100;
|
|
|
|
|
scid = tal(cmd, struct short_channel_id);
|
|
|
|
|
|
|
|
|
|
/*To indicate this is an stub channel we keep it's scid to 1x1x1.*/
|
|
|
|
|
if (!mk_short_channel_id(scid, 1, 1, 1))
|
|
|
|
|
fatal("Failed to make short channel 1x1x1!");
|
|
|
|
|
|
|
|
|
|
/* Channel Shell with Dummy data(mostly) */
|
|
|
|
|
channel = new_channel(peer, id,
|
|
|
|
|
NULL, /* No shachain yet */
|
|
|
|
|
CHANNELD_NORMAL,
|
|
|
|
|
LOCAL,
|
|
|
|
|
NULL,
|
|
|
|
|
"restored from static channel backup",
|
|
|
|
|
0, our_config,
|
|
|
|
|
0,
|
|
|
|
|
1, 1, 1,
|
|
|
|
|
&funding,
|
|
|
|
|
funding_sats,
|
|
|
|
|
AMOUNT_MSAT(0),
|
|
|
|
|
AMOUNT_SAT(0),
|
|
|
|
|
true, /* !remote_funding_locked */
|
|
|
|
|
scid,
|
|
|
|
|
scid,
|
|
|
|
|
scid,
|
|
|
|
|
&cid,
|
|
|
|
|
/* The three arguments below are msatoshi_to_us,
|
|
|
|
|
* msatoshi_to_us_min, and msatoshi_to_us_max.
|
|
|
|
|
* Because, this is a newly-funded channel,
|
|
|
|
|
* all three are same value. */
|
|
|
|
|
AMOUNT_MSAT(0),
|
|
|
|
|
AMOUNT_MSAT(0), /* msat_to_us_min */
|
|
|
|
|
AMOUNT_MSAT(0), /* msat_to_us_max */
|
|
|
|
|
NULL,
|
|
|
|
|
sig,
|
|
|
|
|
NULL, /* No HTLC sigs */
|
|
|
|
|
channel_info,
|
|
|
|
|
new_fee_states(cmd, LOCAL, &feerate),
|
|
|
|
|
NULL, /* No shutdown_scriptpubkey[REMOTE] */
|
|
|
|
|
NULL,
|
|
|
|
|
1, false,
|
|
|
|
|
NULL, /* No commit sent */
|
|
|
|
|
/* If we're fundee, could be a little before this
|
|
|
|
|
* in theory, but it's only used for timing out. */
|
|
|
|
|
get_network_blockheight(ld->topology),
|
|
|
|
|
FEERATE_FLOOR,
|
|
|
|
|
funding_sats.satoshis / MINIMUM_TX_WEIGHT * 1000 /* Raw: convert to feerate */,
|
|
|
|
|
&basepoints,
|
|
|
|
|
&localFundingPubkey,
|
|
|
|
|
NULL,
|
|
|
|
|
ld->config.fee_base,
|
|
|
|
|
ld->config.fee_per_satoshi,
|
|
|
|
|
NULL,
|
|
|
|
|
0, 0,
|
|
|
|
|
type,
|
|
|
|
|
NUM_SIDES, /* closer not yet known */
|
|
|
|
|
REASON_REMOTE,
|
|
|
|
|
NULL,
|
|
|
|
|
take(new_height_states(ld->wallet, LOCAL,
|
|
|
|
|
&blockht)),
|
|
|
|
|
0, NULL, 0, 0, /* No leases on v1s */
|
|
|
|
|
ld->config.htlc_minimum_msat,
|
|
|
|
|
ld->config.htlc_maximum_msat);
|
|
|
|
|
|
|
|
|
|
return channel;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static struct command_result *json_recoverchannel(struct command *cmd,
|
|
|
|
|
const char *buffer,
|
|
|
|
|
const jsmntok_t *obj UNNEEDED,
|
|
|
|
|
const jsmntok_t *params)
|
|
|
|
|
{
|
|
|
|
|
const jsmntok_t *scb, *t;
|
|
|
|
|
size_t i;
|
|
|
|
|
struct json_stream *response;
|
|
|
|
|
struct scb_chan *scb_chan = tal(cmd, struct scb_chan);
|
|
|
|
|
|
|
|
|
|
if (!param(cmd, buffer, params,
|
|
|
|
|
p_req("scb", param_array, &scb),
|
|
|
|
|
NULL))
|
|
|
|
|
return command_param_failed();
|
|
|
|
|
|
|
|
|
|
response = json_stream_success(cmd);
|
|
|
|
|
|
|
|
|
|
json_array_start(response, "stubs");
|
|
|
|
|
json_for_each_arr(i,t,scb){
|
|
|
|
|
|
|
|
|
|
char *token = json_strdup(tmpctx, buffer, t);
|
|
|
|
|
const u8 *scb_arr = tal_hexdata(cmd, token, strlen(token));
|
|
|
|
|
size_t scblen = tal_count(scb_arr);
|
|
|
|
|
|
|
|
|
|
scb_chan = fromwire_scb_chan(cmd ,&scb_arr, &scblen);
|
|
|
|
|
|
|
|
|
|
if (scb_chan == NULL) {
|
|
|
|
|
log_broken(cmd->ld->log, "SCB is invalid!");
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct lightningd *ld = cmd->ld;
|
|
|
|
|
struct channel *channel= stub_chan(cmd,
|
|
|
|
|
scb_chan->id,
|
|
|
|
|
scb_chan->node_id,
|
|
|
|
|
scb_chan->cid,
|
|
|
|
|
scb_chan->funding,
|
|
|
|
|
scb_chan->addr,
|
|
|
|
|
scb_chan->funding_sats,
|
|
|
|
|
scb_chan->type);
|
|
|
|
|
|
|
|
|
|
/* Now we put this in the database. */
|
|
|
|
|
wallet_channel_insert(ld->wallet, channel);
|
|
|
|
|
|
|
|
|
|
/* Watch the Funding */
|
|
|
|
|
channel_watch_funding(ld, channel);
|
|
|
|
|
|
|
|
|
|
json_add_channel_id(response, NULL, &scb_chan->cid);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* This will try to reconnect to the peers and start
|
|
|
|
|
* initiating the process */
|
|
|
|
|
setup_peers(cmd->ld);
|
|
|
|
|
|
|
|
|
|
json_array_end(response);
|
|
|
|
|
|
|
|
|
|
return command_success(cmd, response);
|
|
|
|
|
}
|
|
|
|
|
|
2021-03-15 03:39:44 +00:00
|
|
|
static const struct json_command fundchannel_start_command = {
|
2019-05-22 00:51:52 +01:00
|
|
|
"fundchannel_start",
|
|
|
|
|
"channels",
|
2021-03-15 03:39:44 +00:00
|
|
|
json_fundchannel_start,
|
2019-05-22 00:51:52 +01:00
|
|
|
"Start fund channel with {id} using {amount} satoshis. "
|
|
|
|
|
"Returns a bech32 address to use as an output for a funding transaction."
|
|
|
|
|
};
|
2021-03-15 03:39:44 +00:00
|
|
|
AUTODATA(json_command, &fundchannel_start_command);
|
2019-05-22 00:51:52 +01:00
|
|
|
|
2021-03-15 03:39:44 +00:00
|
|
|
static const struct json_command fundchannel_cancel_command = {
|
2019-05-31 22:57:04 +01:00
|
|
|
"fundchannel_cancel",
|
|
|
|
|
"channels",
|
2021-03-15 03:39:44 +00:00
|
|
|
json_fundchannel_cancel,
|
2019-05-31 22:57:04 +01:00
|
|
|
"Cancel inflight channel establishment with peer {id}."
|
|
|
|
|
};
|
2021-03-15 03:39:44 +00:00
|
|
|
AUTODATA(json_command, &fundchannel_cancel_command);
|
2019-05-31 22:57:04 +01:00
|
|
|
|
2021-03-15 03:39:44 +00:00
|
|
|
static const struct json_command fundchannel_complete_command = {
|
2019-06-05 01:26:39 +01:00
|
|
|
"fundchannel_complete",
|
2019-05-25 01:40:00 +01:00
|
|
|
"channels",
|
2021-03-15 03:39:44 +00:00
|
|
|
json_fundchannel_complete,
|
2019-05-25 01:40:00 +01:00
|
|
|
"Complete channel establishment with peer {id} for funding transaction"
|
2021-03-15 04:27:56 +00:00
|
|
|
"with {psbt}. Returns true on success, false otherwise."
|
2019-05-25 01:40:00 +01:00
|
|
|
};
|
2021-03-15 03:39:44 +00:00
|
|
|
AUTODATA(json_command, &fundchannel_complete_command);
|
2022-06-24 02:14:11 +01:00
|
|
|
|
|
|
|
|
static const struct json_command json_commitchan_command = {
|
|
|
|
|
"recoverchannel",
|
|
|
|
|
"channels",
|
|
|
|
|
json_recoverchannel,
|
|
|
|
|
"Populate the DB with a channel and peer"
|
|
|
|
|
"Used for recovering the channel using DLP."
|
|
|
|
|
"This needs param in the form of an array [scb1,scb2,...]"
|
|
|
|
|
};
|
|
|
|
|
AUTODATA(json_command, &json_commitchan_command);
|
