2018-12-10 23:35:36 +01:00
|
|
|
/*~ Welcome to the opening daemon: gateway to channels!
|
|
|
|
*
|
|
|
|
* This daemon handles a single peer. It's happy to trade gossip with the
|
|
|
|
* peer until either lightningd asks it to fund a channel, or the peer itself
|
|
|
|
* asks to fund a channel. Then it goes through with the channel opening
|
|
|
|
* negotiations. It's important to note that until this negotiation is complete,
|
|
|
|
* there's nothing permanent about the channel: lightningd will only have to
|
|
|
|
* commit to the database once openingd succeeds.
|
|
|
|
*/
|
2021-12-04 12:23:56 +01:00
|
|
|
#include "config.h"
|
2017-02-21 05:45:29 +01:00
|
|
|
#include <bitcoin/script.h>
|
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 16:10:58 +02:00
|
|
|
#include <ccan/array_size/array_size.h>
|
2017-02-21 05:45:29 +01:00
|
|
|
#include <ccan/breakpoint/breakpoint.h>
|
2017-12-06 04:22:35 +01:00
|
|
|
#include <ccan/tal/str/str.h>
|
2021-09-09 04:50:52 +02:00
|
|
|
#include <common/channel_type.h>
|
2019-12-12 15:07:53 +01:00
|
|
|
#include <common/fee_states.h>
|
2019-06-03 20:15:25 +02:00
|
|
|
#include <common/gossip_store.h>
|
2017-08-28 18:02:01 +02:00
|
|
|
#include <common/initial_channel.h>
|
2018-11-22 03:17:29 +01:00
|
|
|
#include <common/memleak.h>
|
2018-02-23 06:53:47 +01:00
|
|
|
#include <common/peer_billboard.h>
|
2017-08-28 18:05:01 +02:00
|
|
|
#include <common/peer_failed.h>
|
2022-01-08 14:23:29 +01:00
|
|
|
#include <common/peer_io.h>
|
2022-01-08 14:29:29 +01:00
|
|
|
#include <common/per_peer_state.h>
|
2018-01-31 03:53:42 +01:00
|
|
|
#include <common/read_peer_msg.h>
|
2017-08-28 18:05:01 +02:00
|
|
|
#include <common/status.h>
|
2018-01-08 11:01:09 +01:00
|
|
|
#include <common/subdaemon.h>
|
2017-08-28 18:02:01 +02:00
|
|
|
#include <common/type_to_string.h>
|
2017-12-06 04:22:35 +01:00
|
|
|
#include <common/wire_error.h>
|
2017-02-21 05:45:29 +01:00
|
|
|
#include <errno.h>
|
2020-08-25 03:55:38 +02:00
|
|
|
#include <hsmd/hsmd_wiregen.h>
|
2020-09-09 09:20:53 +02:00
|
|
|
#include <openingd/common.h>
|
2020-08-25 04:12:18 +02:00
|
|
|
#include <openingd/openingd_wiregen.h>
|
2017-05-05 08:41:45 +02:00
|
|
|
#include <wire/peer_wire.h>
|
2017-02-21 05:45:29 +01:00
|
|
|
#include <wire/wire_sync.h>
|
|
|
|
|
2022-01-29 04:33:05 +01:00
|
|
|
/* stdin == lightningd, 3 == peer, 4 = hsmd */
|
2017-02-21 05:45:29 +01:00
|
|
|
#define REQ_FD STDIN_FILENO
|
2022-01-29 04:33:05 +01:00
|
|
|
#define HSM_FD 4
|
2017-02-21 05:45:29 +01:00
|
|
|
|
2019-11-01 18:01:54 +01:00
|
|
|
#if DEVELOPER
|
|
|
|
/* If --dev-force-tmp-channel-id is set, it ends up here */
|
|
|
|
static struct channel_id *dev_force_tmp_channel_id;
|
|
|
|
#endif /* DEVELOPER */
|
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* Global state structure. This is only for the one specific peer and channel */
|
2017-02-21 05:45:29 +01:00
|
|
|
struct state {
|
2019-06-03 20:11:25 +02:00
|
|
|
struct per_peer_state *pps;
|
2017-02-21 05:45:29 +01:00
|
|
|
|
2019-05-01 00:58:09 +02:00
|
|
|
/* Features they offered */
|
2020-04-03 02:03:59 +02:00
|
|
|
u8 *their_features;
|
2019-05-01 00:58:09 +02:00
|
|
|
|
2018-12-10 23:35:37 +01:00
|
|
|
/* Constraints on a channel they open. */
|
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 16:10:58 +02:00
|
|
|
u32 minimum_depth;
|
|
|
|
u32 min_feerate, max_feerate;
|
2019-02-21 04:45:54 +01:00
|
|
|
struct amount_msat 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 16:10:58 +02:00
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* Limits on what remote config we accept. */
|
2018-12-10 23:26:32 +01:00
|
|
|
u32 max_to_self_delay;
|
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* These are the points lightningd told us to use when accepting or
|
|
|
|
* opening a channel. */
|
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 16:10:58 +02:00
|
|
|
struct basepoints our_points;
|
|
|
|
struct pubkey our_funding_pubkey;
|
|
|
|
|
2019-06-05 02:26:39 +02:00
|
|
|
/* Information we need between funding_start and funding_complete */
|
2019-05-31 23:46:04 +02:00
|
|
|
struct basepoints their_points;
|
|
|
|
struct pubkey their_funding_pubkey;
|
|
|
|
|
2018-12-12 03:28:02 +01:00
|
|
|
/* hsmd gives us our first per-commitment point, and peer tells us
|
2018-12-10 23:35:36 +01:00
|
|
|
* theirs */
|
|
|
|
struct pubkey first_per_commitment_point[NUM_SIDES];
|
|
|
|
|
2017-09-06 03:25:49 +02:00
|
|
|
/* Initially temporary, then final channel id. */
|
|
|
|
struct channel_id channel_id;
|
|
|
|
|
2017-02-21 05:45:29 +01:00
|
|
|
/* Funding and feerate: set by opening peer. */
|
2021-10-13 05:45:36 +02:00
|
|
|
struct amount_sat funding_sats;
|
2019-02-21 04:45:54 +01:00
|
|
|
struct amount_msat push_msat;
|
2017-02-21 05:45:29 +01:00
|
|
|
u32 feerate_per_kw;
|
2021-10-13 05:45:36 +02:00
|
|
|
struct bitcoin_outpoint funding;
|
2019-11-27 03:44:13 +01:00
|
|
|
|
|
|
|
/* If non-NULL, this is the scriptpubkey we/they *must* close with */
|
|
|
|
u8 *upfront_shutdown_script[NUM_SIDES];
|
2017-02-21 05:45:29 +01:00
|
|
|
|
2021-11-04 18:48:43 +01:00
|
|
|
/* If non-NULL, the wallet index for the LOCAL script */
|
|
|
|
u32 *local_upfront_shutdown_wallet_index;
|
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* This is a cluster of fields in open_channel and accept_channel which
|
|
|
|
* indicate the restrictions each side places on the channel. */
|
2018-08-09 02:25:29 +02:00
|
|
|
struct channel_config localconf, remoteconf;
|
2017-02-24 06:52:56 +01:00
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* The channel structure, as defined in common/initial_channel.h. While
|
|
|
|
* the structure has room for HTLCs, those routines are channeld-specific
|
|
|
|
* as initial channels never have HTLCs. */
|
2017-02-21 05:45:29 +01:00
|
|
|
struct channel *channel;
|
2017-07-11 15:50:10 +02:00
|
|
|
|
2021-09-10 04:14:16 +02:00
|
|
|
/* Channel type we agreed on (even before channel populated) */
|
|
|
|
struct channel_type *channel_type;
|
|
|
|
|
2020-04-03 02:03:59 +02:00
|
|
|
struct feature_set *our_features;
|
2022-06-09 13:34:33 +02:00
|
|
|
|
|
|
|
struct amount_sat *reserve;
|
2022-06-22 15:31:27 +02:00
|
|
|
|
|
|
|
bool allowdustreserve;
|
2017-02-21 05:45:29 +01:00
|
|
|
};
|
|
|
|
|
2022-03-22 21:26:29 +01:00
|
|
|
/*~ If we can't agree on parameters, we fail to open the channel.
|
|
|
|
* Tell lightningd why. */
|
|
|
|
static void NORETURN negotiation_aborted(struct state *state, const char *why)
|
2018-08-09 02:25:29 +02:00
|
|
|
{
|
2018-12-10 23:35:36 +01:00
|
|
|
status_debug("aborted opening negotiation: %s", why);
|
|
|
|
/*~ The "billboard" (exposed as "status" in the JSON listpeers RPC
|
|
|
|
* call) is a transient per-channel area which indicates important
|
2018-12-10 23:35:37 +01:00
|
|
|
* information about what is happening. It has a "permanent" area for
|
2018-12-10 23:35:36 +01:00
|
|
|
* each state, which can be used to indicate what went wrong in that
|
|
|
|
* state (such as here), and a single transient area for current
|
|
|
|
* status. */
|
2018-08-09 02:25:29 +02:00
|
|
|
peer_billboard(true, why);
|
|
|
|
|
2022-03-22 21:26:29 +01:00
|
|
|
/* Tell master that funding failed. */
|
|
|
|
wire_sync_write(REQ_FD, take(towire_openingd_failed(NULL, why)));
|
|
|
|
exit(0);
|
2018-08-09 02:25:29 +02:00
|
|
|
}
|
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/*~ For negotiation failures: we tell them the parameter we didn't like. */
|
2022-03-22 21:26:29 +01:00
|
|
|
static void NORETURN negotiation_failed(struct state *state,
|
|
|
|
const char *fmt, ...)
|
2017-12-06 04:22:35 +01:00
|
|
|
{
|
|
|
|
va_list ap;
|
|
|
|
const char *errmsg;
|
2018-03-19 00:25:46 +01:00
|
|
|
u8 *msg;
|
2017-12-06 04:22:35 +01:00
|
|
|
|
|
|
|
va_start(ap, fmt);
|
2018-08-09 02:25:29 +02:00
|
|
|
errmsg = tal_vfmt(tmpctx, fmt, ap);
|
2017-12-06 04:22:35 +01:00
|
|
|
va_end(ap);
|
|
|
|
|
2018-08-09 02:25:29 +02:00
|
|
|
msg = towire_errorfmt(NULL, &state->channel_id,
|
|
|
|
"You gave bad parameters: %s", errmsg);
|
2022-01-08 14:23:29 +01:00
|
|
|
peer_write(state->pps, take(msg));
|
2018-08-09 02:25:29 +02:00
|
|
|
|
2022-03-22 21:26:29 +01:00
|
|
|
negotiation_aborted(state, errmsg);
|
2017-12-06 04:22:35 +01:00
|
|
|
}
|
|
|
|
|
2022-06-08 10:36:30 +02:00
|
|
|
static void set_reserve_absolute(struct state * state, const struct amount_sat dust_limit, struct amount_sat reserve_sat)
|
2017-02-24 06:52:56 +01:00
|
|
|
{
|
2022-06-08 10:36:30 +02:00
|
|
|
status_debug("Setting their reserve to %s",
|
|
|
|
type_to_string(tmpctx, struct amount_sat, &reserve_sat));
|
2022-06-24 12:58:26 +02:00
|
|
|
if (state->allowdustreserve) {
|
2022-06-08 10:36:30 +02:00
|
|
|
state->localconf.channel_reserve = reserve_sat;
|
2022-06-24 12:58:26 +02:00
|
|
|
} else {
|
|
|
|
/* BOLT #2:
|
|
|
|
*
|
|
|
|
* The sending node:
|
|
|
|
*...
|
|
|
|
* - MUST set `channel_reserve_satoshis` greater than or equal
|
|
|
|
*to `dust_limit_satoshis` from the `open_channel` message.
|
|
|
|
*/
|
|
|
|
if (amount_sat_greater(dust_limit, reserve_sat)) {
|
|
|
|
status_debug("Their reserve is too small, bumping to "
|
|
|
|
"dust_limit: %s < %s",
|
|
|
|
type_to_string(tmpctx, struct amount_sat,
|
|
|
|
&reserve_sat),
|
|
|
|
type_to_string(tmpctx, struct amount_sat,
|
|
|
|
&dust_limit));
|
|
|
|
state->localconf.channel_reserve = dust_limit;
|
|
|
|
} else {
|
|
|
|
state->localconf.channel_reserve = reserve_sat;
|
|
|
|
}
|
2022-06-08 10:36:30 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We always set channel_reserve_satoshis to 1%, rounded down. */
|
|
|
|
static void set_reserve(struct state *state, const struct amount_sat dust_limit)
|
|
|
|
{
|
|
|
|
set_reserve_absolute(state, dust_limit,
|
|
|
|
amount_sat_div(state->funding_sats, 100));
|
2017-02-24 06:52:56 +01:00
|
|
|
}
|
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/*~ Handle random messages we might get during opening negotiation, (eg. gossip)
|
2018-08-09 02:25:29 +02:00
|
|
|
* returning the first non-handled one, or NULL if we aborted negotiation. */
|
|
|
|
static u8 *opening_negotiate_msg(const tal_t *ctx, struct state *state,
|
2021-12-28 00:24:09 +01:00
|
|
|
const struct channel_id *alternate)
|
2018-01-30 01:44:08 +01:00
|
|
|
{
|
2018-12-10 23:35:36 +01:00
|
|
|
/* This is an event loop of its own. That's generally considered poor
|
2018-12-10 23:35:37 +01:00
|
|
|
* form, but we use it in a very limited way. */
|
2018-08-02 08:49:56 +02:00
|
|
|
for (;;) {
|
|
|
|
u8 *msg;
|
2018-08-09 02:25:29 +02:00
|
|
|
char *err;
|
2021-02-02 13:47:01 +01:00
|
|
|
bool warning;
|
2018-08-09 02:25:29 +02:00
|
|
|
struct channel_id actual;
|
2018-01-30 01:44:08 +01:00
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* The event loop is responsible for freeing tmpctx, so our
|
|
|
|
* temporary allocations don't grow unbounded. */
|
2018-03-15 05:30:37 +01:00
|
|
|
clean_tmpctx();
|
2018-12-10 23:35:36 +01:00
|
|
|
|
|
|
|
/* This helper routine polls both the peer and gossipd. */
|
2022-01-29 04:33:05 +01:00
|
|
|
msg = peer_read(ctx, state->pps);
|
2018-08-09 02:25:29 +02:00
|
|
|
|
2019-08-05 06:48:05 +02:00
|
|
|
/* BOLT #1:
|
|
|
|
*
|
|
|
|
* A receiving node:
|
|
|
|
* - upon receiving a message of _odd_, unknown type:
|
|
|
|
* - MUST ignore the received message.
|
|
|
|
*/
|
|
|
|
if (is_unknown_msg_discardable(msg))
|
|
|
|
continue;
|
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* A helper which decodes an error. */
|
2018-08-09 02:25:29 +02:00
|
|
|
if (is_peer_error(tmpctx, msg, &state->channel_id,
|
2021-02-02 13:47:01 +01:00
|
|
|
&err, &warning)) {
|
2018-08-09 02:25:29 +02:00
|
|
|
/* BOLT #1:
|
|
|
|
*
|
2022-03-31 11:10:50 +02:00
|
|
|
* - if no existing channel is referred to by `channel_id`:
|
2018-08-09 02:25:29 +02:00
|
|
|
* - MUST ignore the message.
|
|
|
|
*/
|
2018-12-10 23:35:36 +01:00
|
|
|
/* In this case, is_peer_error returns true, but sets
|
|
|
|
* err to NULL */
|
2018-08-09 02:25:29 +02:00
|
|
|
if (!err) {
|
|
|
|
tal_free(msg);
|
|
|
|
continue;
|
|
|
|
}
|
2022-03-22 21:26:29 +01:00
|
|
|
negotiation_aborted(state,
|
2021-02-02 13:46:01 +01:00
|
|
|
tal_fmt(tmpctx, "They sent %s",
|
2019-06-13 06:26:56 +02:00
|
|
|
err));
|
2018-08-09 02:25:29 +02:00
|
|
|
/* Return NULL so caller knows to stop negotiating. */
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/*~ We do not support multiple "live" channels, though the
|
|
|
|
* protocol has a "channel_id" field in all non-gossip messages
|
|
|
|
* so it's possible. Our one-process-one-channel mechanism
|
|
|
|
* keeps things simple: if we wanted to change this, we would
|
2018-12-12 03:28:02 +01:00
|
|
|
* probably be best with another daemon to de-multiplex them;
|
2018-12-10 23:35:36 +01:00
|
|
|
* this could be connectd itself, in fact. */
|
2021-12-28 00:24:09 +01:00
|
|
|
if (is_wrong_channel(msg, &state->channel_id, &actual)
|
|
|
|
&& is_wrong_channel(msg, alternate, &actual)) {
|
2019-09-08 18:39:26 +02:00
|
|
|
status_debug("Rejecting %s for unknown channel_id %s",
|
2020-08-31 03:13:25 +02:00
|
|
|
peer_wire_name(fromwire_peektype(msg)),
|
2018-08-09 02:25:29 +02:00
|
|
|
type_to_string(tmpctx, struct channel_id,
|
|
|
|
&actual));
|
2022-01-08 14:23:29 +01:00
|
|
|
peer_write(state->pps,
|
|
|
|
take(towire_errorfmt(NULL, &actual,
|
|
|
|
"Multiple channels"
|
|
|
|
" unsupported")));
|
2018-08-09 02:25:29 +02:00
|
|
|
tal_free(msg);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* If we get here, it's an interesting message. */
|
2018-08-09 02:25:29 +02:00
|
|
|
return msg;
|
2018-08-02 08:49:56 +02:00
|
|
|
}
|
2017-05-05 08:41:45 +02:00
|
|
|
}
|
2018-12-10 23:35:36 +01:00
|
|
|
|
2019-05-22 23:23:35 +02:00
|
|
|
static bool setup_channel_funder(struct state *state)
|
|
|
|
{
|
2019-11-01 18:01:54 +01:00
|
|
|
#if DEVELOPER
|
|
|
|
/* --dev-force-tmp-channel-id specified */
|
|
|
|
if (dev_force_tmp_channel_id)
|
|
|
|
state->channel_id = *dev_force_tmp_channel_id;
|
|
|
|
#endif
|
2019-05-22 23:23:35 +02:00
|
|
|
/* BOLT #2:
|
|
|
|
*
|
|
|
|
* The sending node:
|
|
|
|
*...
|
2020-04-03 02:03:55 +02:00
|
|
|
* - 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.
|
2019-05-22 23:23:35 +02:00
|
|
|
*/
|
2020-04-03 02:03:59 +02:00
|
|
|
if (!feature_negotiated(state->our_features,
|
|
|
|
state->their_features, OPT_LARGE_CHANNELS)
|
2021-10-13 05:45:36 +02:00
|
|
|
&& amount_sat_greater(state->funding_sats,
|
|
|
|
chainparams->max_funding)) {
|
2019-05-22 23:23:35 +02:00
|
|
|
status_failed(STATUS_FAIL_MASTER_IO,
|
|
|
|
"funding_satoshis must be < %s, not %s",
|
|
|
|
type_to_string(tmpctx, struct amount_sat,
|
2019-11-20 02:55:35 +01:00
|
|
|
&chainparams->max_funding),
|
2019-05-22 23:23:35 +02:00
|
|
|
type_to_string(tmpctx, struct amount_sat,
|
2021-10-13 05:45:36 +02:00
|
|
|
&state->funding_sats));
|
2019-05-22 23:23:35 +02:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2021-02-19 05:22:02 +01:00
|
|
|
static void set_remote_upfront_shutdown(struct state *state,
|
|
|
|
u8 *shutdown_scriptpubkey STEALS)
|
|
|
|
{
|
2022-10-19 18:58:49 +02:00
|
|
|
char *err;
|
2021-02-24 03:53:12 +01:00
|
|
|
|
2022-10-19 18:58:49 +02:00
|
|
|
err = validate_remote_upfront_shutdown(state, state->our_features,
|
|
|
|
state->their_features,
|
|
|
|
shutdown_scriptpubkey,
|
|
|
|
&state->upfront_shutdown_script[REMOTE]);
|
|
|
|
|
|
|
|
if (err)
|
|
|
|
peer_failed_err(state->pps, &state->channel_id, "%s", err);
|
2021-02-19 05:22:02 +01:00
|
|
|
}
|
|
|
|
|
openingd: work harder to intuit OPT_SCID_ALIAS.
option_scid_alias inside a channel_type allows for more private
channels: in particular, it tells the peer that it MUST NOT allow
routing via the real short channel id, and MUST use the alias.
It only makes sense (and is only permitted!) on unannounced channels.
Unfortunately, we didn't set this bit in the channel_type in v12.0
when it was introduced, instead relying on the presence of the feature
bit with the peer. This was fixed in 23.05, but:
1. Prior to 23.05 we didn't allow it to be set at all, and
2. LND has a limited set of features they allow, and this isn't allowed without
option_anchors_zero_fee_htlc_tx.
We could simply drop this channel_type until we merge anchors, *but*
that has nasty privacy implications (you can probe the real channel id).
So, if we don't negotiate anchors (we don't!), we don't set this
channel_type bit even if we want it, and *intuit* it, based on:
1. Is this a non-anchor channel_type?
2. Did we both send channel_type?
3. Is this an unannounced channel?
4. Did both peers announce support for scid aliases?
In addition, while looking at the previous backwards-compat code, I
realized that v23.05 violated the spec and send accept_channel with
OPT_SCID_ALIAS if it intuited it, even if it wasn't offered. Stop
doing this, but allow our peers to.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Fix incompatibility with LND which prevented us opening private channels
Fixes: #6208
2023-06-06 04:30:39 +02:00
|
|
|
/* Since we can't send OPT_SCID_ALIAS due to compat issues, intuit whether
|
|
|
|
* we really actually want it anyway, we just can't say that. */
|
|
|
|
static bool intuit_scid_alias_type(struct state *state, u8 channel_flags,
|
|
|
|
bool peer_sent_channel_type)
|
|
|
|
{
|
|
|
|
/* Don't need to intuit if actually set */
|
|
|
|
if (channel_type_has(state->channel_type, OPT_SCID_ALIAS))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* Old clients didn't send channel_type at all */
|
|
|
|
if (!peer_sent_channel_type)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* Modern peer: no intuit hacks necessary. */
|
|
|
|
if (channel_type_has(state->channel_type, OPT_ANCHORS_ZERO_FEE_HTLC_TX))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* Public channel: don't want OPT_SCID_ALIAS which means "only use
|
|
|
|
* alias". */
|
|
|
|
if (channel_flags & CHANNEL_FLAGS_ANNOUNCE_CHANNEL)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* If we both support it, presumably we want it? */
|
|
|
|
return feature_negotiated(state->our_features, state->their_features,
|
|
|
|
OPT_SCID_ALIAS);
|
|
|
|
}
|
|
|
|
|
2019-09-09 18:11:24 +02:00
|
|
|
/* We start the 'open a channel' negotation with the supplied peer, but
|
2019-05-22 01:51:52 +02:00
|
|
|
* stop when we get to the part where we need the funding txid */
|
2023-06-26 01:11:21 +02:00
|
|
|
static u8 *funder_channel_start(struct state *state, u8 channel_flags,
|
|
|
|
u32 nonanchor_feerate, u32 anchor_feerate)
|
2019-05-22 01:51:52 +02:00
|
|
|
{
|
2019-05-23 01:25:22 +02:00
|
|
|
u8 *msg;
|
|
|
|
u8 *funding_output_script;
|
2019-05-31 23:46:04 +02:00
|
|
|
struct channel_id id_in;
|
2020-06-22 07:06:03 +02:00
|
|
|
struct tlv_open_channel_tlvs *open_tlvs;
|
|
|
|
struct tlv_accept_channel_tlvs *accept_tlvs;
|
2020-09-09 09:20:53 +02:00
|
|
|
char *err_reason;
|
2022-05-20 15:41:56 +02:00
|
|
|
u32 their_mindepth;
|
2019-05-23 01:25:22 +02:00
|
|
|
|
2022-03-22 21:27:29 +01:00
|
|
|
status_debug("funder_channel_start");
|
2019-05-23 01:25:22 +02:00
|
|
|
if (!setup_channel_funder(state))
|
|
|
|
return NULL;
|
|
|
|
|
2022-06-09 13:34:33 +02:00
|
|
|
/* If we have a reserve override we use that, otherwise we'll
|
|
|
|
* use our default of 1% of the funding value. */
|
|
|
|
if (state->reserve != NULL) {
|
|
|
|
set_reserve_absolute(state, state->localconf.dust_limit,
|
|
|
|
*state->reserve);
|
|
|
|
} else {
|
|
|
|
set_reserve(state, state->localconf.dust_limit);
|
|
|
|
}
|
|
|
|
|
2019-11-27 03:44:13 +01:00
|
|
|
if (!state->upfront_shutdown_script[LOCAL])
|
2020-12-15 19:28:04 +01:00
|
|
|
state->upfront_shutdown_script[LOCAL]
|
|
|
|
= no_upfront_shutdown_script(state,
|
|
|
|
state->our_features,
|
|
|
|
state->their_features);
|
2019-10-15 03:08:33 +02:00
|
|
|
|
2021-09-10 04:14:23 +02:00
|
|
|
state->channel_type = default_channel_type(state,
|
|
|
|
state->our_features,
|
|
|
|
state->their_features);
|
|
|
|
|
2023-04-10 02:20:56 +02:00
|
|
|
/* Spec says we should use the option_scid_alias variation if we
|
openingd: work harder to intuit OPT_SCID_ALIAS.
option_scid_alias inside a channel_type allows for more private
channels: in particular, it tells the peer that it MUST NOT allow
routing via the real short channel id, and MUST use the alias.
It only makes sense (and is only permitted!) on unannounced channels.
Unfortunately, we didn't set this bit in the channel_type in v12.0
when it was introduced, instead relying on the presence of the feature
bit with the peer. This was fixed in 23.05, but:
1. Prior to 23.05 we didn't allow it to be set at all, and
2. LND has a limited set of features they allow, and this isn't allowed without
option_anchors_zero_fee_htlc_tx.
We could simply drop this channel_type until we merge anchors, *but*
that has nasty privacy implications (you can probe the real channel id).
So, if we don't negotiate anchors (we don't!), we don't set this
channel_type bit even if we want it, and *intuit* it, based on:
1. Is this a non-anchor channel_type?
2. Did we both send channel_type?
3. Is this an unannounced channel?
4. Did both peers announce support for scid aliases?
In addition, while looking at the previous backwards-compat code, I
realized that v23.05 violated the spec and send accept_channel with
OPT_SCID_ALIAS if it intuited it, even if it wasn't offered. Stop
doing this, but allow our peers to.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Fix incompatibility with LND which prevented us opening private channels
Fixes: #6208
2023-06-06 04:30:39 +02:00
|
|
|
* want them to *only* use the scid_alias (which we do for unannounced
|
|
|
|
* channels!).
|
|
|
|
*
|
|
|
|
* But:
|
|
|
|
* 1. We didn't accept this in CLN prior to v23.05.
|
|
|
|
* 2. LND won't accept that without OPT_ANCHORS_ZERO_FEE_HTLC_TX.
|
|
|
|
*
|
|
|
|
* So we keep it off for now, until anchors merge.
|
|
|
|
*/
|
|
|
|
if (channel_type_has(state->channel_type, OPT_ANCHORS_ZERO_FEE_HTLC_TX)) {
|
2023-04-10 02:20:56 +02:00
|
|
|
if (!(channel_flags & CHANNEL_FLAGS_ANNOUNCE_CHANNEL))
|
|
|
|
channel_type_set_scid_alias(state->channel_type);
|
|
|
|
}
|
|
|
|
|
2023-06-26 01:11:21 +02:00
|
|
|
/* Which feerate do we use? (We can lowball fees if using anchors!) */
|
|
|
|
if (channel_type_has(state->channel_type, OPT_ANCHOR_OUTPUTS)
|
|
|
|
|| channel_type_has(state->channel_type, OPT_ANCHORS_ZERO_FEE_HTLC_TX)) {
|
|
|
|
state->feerate_per_kw = anchor_feerate;
|
|
|
|
} else {
|
|
|
|
state->feerate_per_kw = nonanchor_feerate;
|
|
|
|
}
|
|
|
|
|
2020-06-22 07:06:03 +02:00
|
|
|
open_tlvs = tlv_open_channel_tlvs_new(tmpctx);
|
|
|
|
open_tlvs->upfront_shutdown_script
|
|
|
|
= state->upfront_shutdown_script[LOCAL];
|
|
|
|
|
2021-09-10 04:14:24 +02:00
|
|
|
/* BOLT #2:
|
2021-09-10 04:14:23 +02:00
|
|
|
* - if it includes `channel_type`:
|
|
|
|
* - MUST set it to a defined type representing the type it wants.
|
|
|
|
* - MUST use the smallest bitmap possible to represent the channel
|
|
|
|
* type.
|
|
|
|
* - SHOULD NOT set it to a type containing a feature which was not
|
|
|
|
* negotiated.
|
|
|
|
*/
|
|
|
|
open_tlvs->channel_type = state->channel_type->features;
|
|
|
|
|
2020-06-22 07:06:03 +02:00
|
|
|
msg = towire_open_channel(NULL,
|
2019-11-20 02:55:35 +01:00
|
|
|
&chainparams->genesis_blockhash,
|
2019-05-23 01:25:22 +02:00
|
|
|
&state->channel_id,
|
2021-10-13 05:45:36 +02:00
|
|
|
state->funding_sats,
|
2019-05-23 01:25:22 +02:00
|
|
|
state->push_msat,
|
|
|
|
state->localconf.dust_limit,
|
|
|
|
state->localconf.max_htlc_value_in_flight,
|
|
|
|
state->localconf.channel_reserve,
|
|
|
|
state->localconf.htlc_minimum,
|
|
|
|
state->feerate_per_kw,
|
|
|
|
state->localconf.to_self_delay,
|
|
|
|
state->localconf.max_accepted_htlcs,
|
|
|
|
&state->our_funding_pubkey,
|
|
|
|
&state->our_points.revocation,
|
|
|
|
&state->our_points.payment,
|
|
|
|
&state->our_points.delayed_payment,
|
|
|
|
&state->our_points.htlc,
|
|
|
|
&state->first_per_commitment_point[LOCAL],
|
|
|
|
channel_flags,
|
2020-06-22 07:06:03 +02:00
|
|
|
open_tlvs);
|
2022-01-08 14:23:29 +01:00
|
|
|
peer_write(state->pps, take(msg));
|
2019-05-23 01:25:22 +02:00
|
|
|
|
|
|
|
/* This is usually a very transient state... */
|
|
|
|
peer_billboard(false,
|
|
|
|
"Funding channel start: offered, now waiting for accept_channel");
|
|
|
|
|
|
|
|
/* ... since their reply should be immediate. */
|
2022-03-22 21:26:29 +01:00
|
|
|
msg = opening_negotiate_msg(tmpctx, state, NULL);
|
2019-05-23 01:25:22 +02:00
|
|
|
if (!msg)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/* BOLT #2:
|
|
|
|
*
|
|
|
|
* The receiving node MUST fail the channel if:
|
|
|
|
*...
|
|
|
|
* - `funding_pubkey`, `revocation_basepoint`, `htlc_basepoint`,
|
|
|
|
* `payment_basepoint`, or `delayed_payment_basepoint` are not
|
2020-03-31 00:38:58 +02:00
|
|
|
* valid secp256k1 pubkeys in compressed format.
|
2019-05-23 01:25:22 +02:00
|
|
|
*/
|
2022-03-23 00:31:14 +01:00
|
|
|
if (!fromwire_accept_channel(tmpctx, msg, &id_in,
|
2019-05-23 01:25:22 +02:00
|
|
|
&state->remoteconf.dust_limit,
|
|
|
|
&state->remoteconf.max_htlc_value_in_flight,
|
|
|
|
&state->remoteconf.channel_reserve,
|
|
|
|
&state->remoteconf.htlc_minimum,
|
2022-05-20 15:41:56 +02:00
|
|
|
&their_mindepth,
|
2019-05-23 01:25:22 +02:00
|
|
|
&state->remoteconf.to_self_delay,
|
|
|
|
&state->remoteconf.max_accepted_htlcs,
|
2019-05-31 23:46:04 +02:00
|
|
|
&state->their_funding_pubkey,
|
|
|
|
&state->their_points.revocation,
|
|
|
|
&state->their_points.payment,
|
|
|
|
&state->their_points.delayed_payment,
|
|
|
|
&state->their_points.htlc,
|
2019-05-23 01:25:22 +02:00
|
|
|
&state->first_per_commitment_point[REMOTE],
|
2022-03-23 00:31:14 +01:00
|
|
|
&accept_tlvs)) {
|
2021-02-02 13:49:01 +01:00
|
|
|
peer_failed_err(state->pps,
|
|
|
|
&state->channel_id,
|
|
|
|
"Parsing accept_channel %s", tal_hex(msg, msg));
|
2020-06-22 07:06:03 +02:00
|
|
|
}
|
2021-02-19 05:22:02 +01:00
|
|
|
set_remote_upfront_shutdown(state, accept_tlvs->upfront_shutdown_script);
|
2019-05-23 01:25:22 +02:00
|
|
|
|
2022-05-20 15:41:56 +02:00
|
|
|
status_debug(
|
|
|
|
"accept_channel: max_htlc_value_in_flight=%s, channel_reserve=%s, "
|
|
|
|
"htlc_minimum=%s, minimum_depth=%d",
|
|
|
|
type_to_string(tmpctx, struct amount_msat,
|
|
|
|
&state->remoteconf.max_htlc_value_in_flight),
|
|
|
|
type_to_string(tmpctx, struct amount_sat,
|
|
|
|
&state->remoteconf.channel_reserve),
|
|
|
|
type_to_string(tmpctx, struct amount_msat,
|
|
|
|
&state->remoteconf.htlc_minimum),
|
|
|
|
their_mindepth);
|
|
|
|
|
2021-09-10 04:14:24 +02:00
|
|
|
/* BOLT #2:
|
2021-09-10 04:14:23 +02:00
|
|
|
* - if `channel_type` is set, and `channel_type` was set in
|
|
|
|
* `open_channel`, and they are not equal types:
|
|
|
|
* - MUST reject the channel.
|
|
|
|
*/
|
openingd: work harder to intuit OPT_SCID_ALIAS.
option_scid_alias inside a channel_type allows for more private
channels: in particular, it tells the peer that it MUST NOT allow
routing via the real short channel id, and MUST use the alias.
It only makes sense (and is only permitted!) on unannounced channels.
Unfortunately, we didn't set this bit in the channel_type in v12.0
when it was introduced, instead relying on the presence of the feature
bit with the peer. This was fixed in 23.05, but:
1. Prior to 23.05 we didn't allow it to be set at all, and
2. LND has a limited set of features they allow, and this isn't allowed without
option_anchors_zero_fee_htlc_tx.
We could simply drop this channel_type until we merge anchors, *but*
that has nasty privacy implications (you can probe the real channel id).
So, if we don't negotiate anchors (we don't!), we don't set this
channel_type bit even if we want it, and *intuit* it, based on:
1. Is this a non-anchor channel_type?
2. Did we both send channel_type?
3. Is this an unannounced channel?
4. Did both peers announce support for scid aliases?
In addition, while looking at the previous backwards-compat code, I
realized that v23.05 violated the spec and send accept_channel with
OPT_SCID_ALIAS if it intuited it, even if it wasn't offered. Stop
doing this, but allow our peers to.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Fix incompatibility with LND which prevented us opening private channels
Fixes: #6208
2023-06-06 04:30:39 +02:00
|
|
|
if (accept_tlvs->channel_type) {
|
|
|
|
/* Except that v23.05 could set OPT_SCID_ALIAS in reply! */
|
|
|
|
struct channel_type *atype;
|
|
|
|
|
|
|
|
atype = channel_type_from(tmpctx, accept_tlvs->channel_type);
|
|
|
|
if (!channel_type_has(atype, OPT_ANCHORS_ZERO_FEE_HTLC_TX))
|
|
|
|
featurebits_unset(&atype->features, OPT_SCID_ALIAS);
|
|
|
|
|
|
|
|
if (!channel_type_eq(atype, state->channel_type)) {
|
|
|
|
negotiation_failed(state,
|
|
|
|
"Return unoffered channel_type: %s",
|
|
|
|
fmt_featurebits(tmpctx,
|
|
|
|
accept_tlvs->channel_type));
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If they "accepted" SCID_ALIAS, roll with it. */
|
|
|
|
tal_free(state->channel_type);
|
|
|
|
state->channel_type = channel_type_from(state,
|
|
|
|
accept_tlvs->channel_type);
|
2021-09-10 04:14:23 +02:00
|
|
|
}
|
2021-09-10 04:14:23 +02:00
|
|
|
|
2019-05-23 01:25:22 +02:00
|
|
|
/* BOLT #2:
|
|
|
|
*
|
|
|
|
* The `temporary_channel_id` MUST be the same as the
|
|
|
|
* `temporary_channel_id` in the `open_channel` message. */
|
|
|
|
if (!channel_id_eq(&id_in, &state->channel_id))
|
|
|
|
/* In this case we exit, since we don't know what's going on. */
|
2021-02-02 13:49:01 +01:00
|
|
|
peer_failed_err(state->pps, &id_in,
|
|
|
|
"accept_channel ids don't match: sent %s got %s",
|
|
|
|
type_to_string(msg, struct channel_id, &id_in),
|
|
|
|
type_to_string(msg, struct channel_id,
|
|
|
|
&state->channel_id));
|
2019-05-23 01:25:22 +02:00
|
|
|
|
2022-06-24 12:58:26 +02:00
|
|
|
if (!state->allowdustreserve &&
|
|
|
|
amount_sat_greater(state->remoteconf.dust_limit,
|
2019-05-23 01:25:22 +02:00
|
|
|
state->localconf.channel_reserve)) {
|
2022-03-22 21:26:29 +01:00
|
|
|
negotiation_failed(state,
|
2019-05-23 01:25:22 +02:00
|
|
|
"dust limit %s"
|
|
|
|
" would be above our reserve %s",
|
|
|
|
type_to_string(tmpctx, struct amount_sat,
|
|
|
|
&state->remoteconf.dust_limit),
|
|
|
|
type_to_string(tmpctx, struct amount_sat,
|
|
|
|
&state->localconf.channel_reserve));
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2022-08-16 17:12:37 +02:00
|
|
|
/* If we allow dust reserves, we might end up in a situation
|
|
|
|
* in which all the channel funds are allocated to HTLCs,
|
|
|
|
* leaving just dust to_us and to_them outputs. If the HTLCs
|
|
|
|
* themselves are dust as well, our commitment transaction is
|
|
|
|
* now invalid since it has no outputs at all, putting us in a
|
|
|
|
* weird situation where the channel cannot be closed
|
|
|
|
* unilaterally at all. (Thanks Rusty for identifying this
|
|
|
|
* edge case). */
|
|
|
|
struct amount_sat alldust, mindust =
|
|
|
|
amount_sat_greater(state->remoteconf.dust_limit,
|
|
|
|
state->localconf.dust_limit)
|
|
|
|
? state->localconf.dust_limit
|
|
|
|
: state->remoteconf.dust_limit;
|
|
|
|
size_t maxhtlcs = state->remoteconf.max_accepted_htlcs +
|
|
|
|
state->localconf.max_accepted_htlcs;
|
|
|
|
if (!amount_sat_mul(&alldust, mindust, maxhtlcs + 2)) {
|
|
|
|
negotiation_failed(
|
|
|
|
state,
|
|
|
|
"Overflow while computing total possible dust amount");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (state->allowdustreserve &&
|
|
|
|
feature_negotiated(state->our_features, state->their_features,
|
|
|
|
OPT_ZEROCONF) &&
|
|
|
|
amount_sat_greater_eq(alldust, state->funding_sats)) {
|
|
|
|
negotiation_failed(
|
|
|
|
state,
|
|
|
|
"channel funding %s too small for chosen "
|
|
|
|
"parameters: a total of %zu HTLCs with dust value %s would "
|
|
|
|
"result in a commitment_transaction without outputs. "
|
|
|
|
"Please increase the funding amount or reduce the "
|
|
|
|
"max_accepted_htlcs to ensure at least one non-dust "
|
|
|
|
"output.",
|
|
|
|
type_to_string(tmpctx, struct amount_sat,
|
|
|
|
&state->funding_sats),
|
|
|
|
maxhtlcs,
|
|
|
|
type_to_string(tmpctx, struct amount_sat, &mindust));
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2021-10-13 05:45:36 +02:00
|
|
|
if (!check_config_bounds(tmpctx, state->funding_sats,
|
2020-09-09 09:20:53 +02:00
|
|
|
state->feerate_per_kw,
|
|
|
|
state->max_to_self_delay,
|
|
|
|
state->min_effective_htlc_capacity,
|
|
|
|
&state->remoteconf,
|
|
|
|
&state->localconf,
|
2023-06-26 01:18:21 +02:00
|
|
|
feature_negotiated(state->our_features,
|
|
|
|
state->their_features,
|
|
|
|
OPT_ANCHOR_OUTPUTS),
|
|
|
|
feature_negotiated(state->our_features,
|
|
|
|
state->their_features,
|
|
|
|
OPT_ANCHORS_ZERO_FEE_HTLC_TX),
|
2020-09-09 09:20:53 +02:00
|
|
|
&err_reason)) {
|
2022-03-22 21:26:29 +01:00
|
|
|
negotiation_failed(state, "%s", err_reason);
|
2019-05-23 01:25:22 +02:00
|
|
|
return NULL;
|
2020-09-09 09:20:53 +02:00
|
|
|
}
|
2019-05-23 01:25:22 +02:00
|
|
|
|
|
|
|
funding_output_script =
|
|
|
|
scriptpubkey_p2wsh(tmpctx,
|
|
|
|
bitcoin_redeem_2of2(tmpctx,
|
|
|
|
&state->our_funding_pubkey,
|
2019-05-31 23:46:04 +02:00
|
|
|
&state->their_funding_pubkey));
|
2019-05-23 01:25:22 +02:00
|
|
|
|
2022-05-20 15:41:56 +02:00
|
|
|
/* If we have negotiated `option_zeroconf` then we're allowed
|
|
|
|
* to send `channel_ready` whenever we want. So ignore their
|
|
|
|
* `minimum_depth` and use ours instead. Otherwise we use the
|
|
|
|
* old behavior of using their value and both side will wait
|
|
|
|
* for that number of confirmations. */
|
|
|
|
if (feature_negotiated(state->our_features, state->their_features,
|
|
|
|
OPT_ZEROCONF)) {
|
|
|
|
status_debug(
|
|
|
|
"We negotiated option_zeroconf, using our minimum_depth=%d",
|
|
|
|
state->minimum_depth);
|
|
|
|
} else {
|
|
|
|
state->minimum_depth = their_mindepth;
|
|
|
|
}
|
|
|
|
|
2019-05-24 01:42:57 +02:00
|
|
|
/* Update the billboard with our infos */
|
|
|
|
peer_billboard(false,
|
|
|
|
"Funding channel start: awaiting funding_txid with output to %s",
|
|
|
|
tal_hex(tmpctx, funding_output_script));
|
2019-10-15 03:08:33 +02:00
|
|
|
|
openingd: work harder to intuit OPT_SCID_ALIAS.
option_scid_alias inside a channel_type allows for more private
channels: in particular, it tells the peer that it MUST NOT allow
routing via the real short channel id, and MUST use the alias.
It only makes sense (and is only permitted!) on unannounced channels.
Unfortunately, we didn't set this bit in the channel_type in v12.0
when it was introduced, instead relying on the presence of the feature
bit with the peer. This was fixed in 23.05, but:
1. Prior to 23.05 we didn't allow it to be set at all, and
2. LND has a limited set of features they allow, and this isn't allowed without
option_anchors_zero_fee_htlc_tx.
We could simply drop this channel_type until we merge anchors, *but*
that has nasty privacy implications (you can probe the real channel id).
So, if we don't negotiate anchors (we don't!), we don't set this
channel_type bit even if we want it, and *intuit* it, based on:
1. Is this a non-anchor channel_type?
2. Did we both send channel_type?
3. Is this an unannounced channel?
4. Did both peers announce support for scid aliases?
In addition, while looking at the previous backwards-compat code, I
realized that v23.05 violated the spec and send accept_channel with
OPT_SCID_ALIAS if it intuited it, even if it wasn't offered. Stop
doing this, but allow our peers to.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Fix incompatibility with LND which prevented us opening private channels
Fixes: #6208
2023-06-06 04:30:39 +02:00
|
|
|
/* Backwards/cross compat hack */
|
|
|
|
if (intuit_scid_alias_type(state, channel_flags,
|
|
|
|
accept_tlvs->channel_type != NULL)) {
|
|
|
|
channel_type_set_scid_alias(state->channel_type);
|
|
|
|
}
|
|
|
|
|
2020-08-25 04:12:18 +02:00
|
|
|
return towire_openingd_funder_start_reply(state,
|
2021-09-10 04:14:16 +02:00
|
|
|
funding_output_script,
|
|
|
|
feature_negotiated(
|
|
|
|
state->our_features,
|
|
|
|
state->their_features,
|
|
|
|
OPT_UPFRONT_SHUTDOWN_SCRIPT),
|
|
|
|
state->channel_type);
|
2019-05-22 01:51:52 +02:00
|
|
|
}
|
|
|
|
|
2019-05-31 23:46:04 +02:00
|
|
|
static bool funder_finalize_channel_setup(struct state *state,
|
2019-09-19 02:27:45 +02:00
|
|
|
struct amount_msat local_msat,
|
|
|
|
struct bitcoin_signature *sig,
|
2020-05-07 02:43:42 +02:00
|
|
|
struct bitcoin_tx **tx,
|
|
|
|
struct penalty_base **pbase)
|
2019-05-25 02:40:00 +02:00
|
|
|
{
|
2019-05-31 23:46:04 +02:00
|
|
|
u8 *msg;
|
|
|
|
struct channel_id id_in;
|
|
|
|
const u8 *wscript;
|
2020-09-09 09:20:53 +02:00
|
|
|
struct channel_id cid;
|
2019-09-19 02:27:45 +02:00
|
|
|
char *err_reason;
|
2020-05-07 02:43:34 +02:00
|
|
|
struct wally_tx_output *direct_outputs[NUM_SIDES];
|
2019-05-31 23:46:04 +02:00
|
|
|
|
2021-11-04 18:48:43 +01:00
|
|
|
/*~ Channel is ready; Report the channel parameters to the signer. */
|
|
|
|
msg = towire_hsmd_ready_channel(NULL,
|
|
|
|
true, /* is_outbound */
|
|
|
|
state->funding_sats,
|
|
|
|
state->push_msat,
|
|
|
|
&state->funding.txid,
|
|
|
|
state->funding.n,
|
|
|
|
state->localconf.to_self_delay,
|
|
|
|
state->upfront_shutdown_script[LOCAL],
|
|
|
|
state->local_upfront_shutdown_wallet_index,
|
|
|
|
&state->their_points,
|
|
|
|
&state->their_funding_pubkey,
|
|
|
|
state->remoteconf.to_self_delay,
|
|
|
|
state->upfront_shutdown_script[REMOTE],
|
|
|
|
state->channel_type);
|
|
|
|
wire_sync_write(HSM_FD, take(msg));
|
|
|
|
msg = wire_sync_read(tmpctx, HSM_FD);
|
|
|
|
if (!fromwire_hsmd_ready_channel_reply(msg))
|
|
|
|
status_failed(STATUS_FAIL_HSM_IO, "Bad ready_channel_reply %s",
|
|
|
|
tal_hex(tmpctx, msg));
|
|
|
|
|
2019-05-31 23:46:04 +02:00
|
|
|
/*~ Now we can initialize the `struct channel`. This represents
|
|
|
|
* the current channel state and is how we can generate the current
|
|
|
|
* commitment transaction.
|
|
|
|
*
|
|
|
|
* The routines to support `struct channel` are split into a common
|
|
|
|
* part (common/initial_channel) which doesn't support HTLCs and is
|
|
|
|
* enough for us here, and the complete channel support required by
|
|
|
|
* `channeld` which lives in channeld/full_channel. */
|
2021-10-13 05:45:36 +02:00
|
|
|
derive_channel_id(&cid, &state->funding);
|
2020-09-09 09:20:53 +02:00
|
|
|
|
2019-05-31 23:46:04 +02:00
|
|
|
state->channel = new_initial_channel(state,
|
2020-09-09 09:20:53 +02:00
|
|
|
&cid,
|
2021-10-13 05:45:36 +02:00
|
|
|
&state->funding,
|
2019-05-31 23:46:04 +02:00
|
|
|
state->minimum_depth,
|
2021-06-22 20:25:59 +02:00
|
|
|
NULL, 0, /* No channel lease */
|
2021-10-13 05:45:36 +02:00
|
|
|
state->funding_sats,
|
2019-05-31 23:46:04 +02:00
|
|
|
local_msat,
|
2019-12-12 15:07:53 +01:00
|
|
|
take(new_fee_states(NULL, LOCAL,
|
|
|
|
&state->feerate_per_kw)),
|
2019-05-31 23:46:04 +02:00
|
|
|
&state->localconf,
|
|
|
|
&state->remoteconf,
|
|
|
|
&state->our_points,
|
|
|
|
&state->their_points,
|
|
|
|
&state->our_funding_pubkey,
|
|
|
|
&state->their_funding_pubkey,
|
2021-09-10 04:14:16 +02:00
|
|
|
state->channel_type,
|
2021-09-08 02:06:14 +02:00
|
|
|
feature_offered(state->their_features,
|
|
|
|
OPT_LARGE_CHANNELS),
|
2019-09-19 02:27:45 +02:00
|
|
|
/* Opener is local */
|
2019-05-31 23:46:04 +02:00
|
|
|
LOCAL);
|
|
|
|
/* We were supposed to do enough checks above, but just in case,
|
|
|
|
* new_initial_channel will fail to create absurd channels */
|
|
|
|
if (!state->channel)
|
2021-02-02 13:49:01 +01:00
|
|
|
peer_failed_err(state->pps,
|
|
|
|
&state->channel_id,
|
|
|
|
"could not create channel with given config");
|
2019-05-31 23:46:04 +02:00
|
|
|
|
|
|
|
/* BOLT #2:
|
|
|
|
*
|
|
|
|
* ### The `funding_created` Message
|
|
|
|
*
|
|
|
|
* This message describes the outpoint which the funder has created
|
|
|
|
* for the initial commitment transactions. After receiving the
|
|
|
|
* peer's signature, via `funding_signed`, it will broadcast the funding
|
|
|
|
* transaction.
|
|
|
|
*/
|
|
|
|
/* This gives us their first commitment transaction. */
|
|
|
|
*tx = initial_channel_tx(state, &wscript, state->channel,
|
|
|
|
&state->first_per_commitment_point[REMOTE],
|
2020-05-07 02:43:34 +02:00
|
|
|
REMOTE, direct_outputs, &err_reason);
|
2019-05-31 23:46:04 +02:00
|
|
|
if (!*tx) {
|
|
|
|
/* This should not happen: we should never create channels we
|
|
|
|
* can't afford the fees for after reserve. */
|
2022-03-22 21:26:29 +01:00
|
|
|
negotiation_failed(state,
|
2019-05-31 23:46:04 +02:00
|
|
|
"Could not meet their fees and reserve: %s", err_reason);
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2020-05-07 02:43:42 +02:00
|
|
|
if (direct_outputs[LOCAL])
|
|
|
|
*pbase = penalty_base_new(state, 0, *tx, direct_outputs[LOCAL]);
|
|
|
|
else
|
|
|
|
*pbase = NULL;
|
|
|
|
|
2019-05-31 23:46:04 +02:00
|
|
|
/* We ask the HSM to sign their commitment transaction for us: it knows
|
|
|
|
* our funding key, it just needs the remote funding key to create the
|
|
|
|
* witness script. It also needs the amount of the funding output,
|
|
|
|
* as segwit signatures commit to that as well, even though it doesn't
|
|
|
|
* explicitly appear in the transaction itself. */
|
2021-12-15 02:37:35 +01:00
|
|
|
struct simple_htlc **htlcs = tal_arr(tmpctx, struct simple_htlc *, 0);
|
|
|
|
u32 feerate = 0; // unused since there are no htlcs
|
|
|
|
u64 commit_num = 0;
|
2020-08-25 03:55:38 +02:00
|
|
|
msg = towire_hsmd_sign_remote_commitment_tx(NULL,
|
2019-05-31 23:46:04 +02:00
|
|
|
*tx,
|
|
|
|
&state->channel->funding_pubkey[REMOTE],
|
2020-02-04 01:10:43 +01:00
|
|
|
&state->first_per_commitment_point[REMOTE],
|
2021-09-09 07:25:23 +02:00
|
|
|
channel_has(state->channel,
|
2021-12-15 02:37:35 +01:00
|
|
|
OPT_STATIC_REMOTEKEY),
|
|
|
|
commit_num,
|
|
|
|
(const struct simple_htlc **) htlcs,
|
|
|
|
feerate);
|
2019-05-31 23:46:04 +02:00
|
|
|
|
|
|
|
wire_sync_write(HSM_FD, take(msg));
|
|
|
|
msg = wire_sync_read(tmpctx, HSM_FD);
|
2020-08-25 03:55:38 +02:00
|
|
|
if (!fromwire_hsmd_sign_tx_reply(msg, sig))
|
2019-05-31 23:46:04 +02:00
|
|
|
status_failed(STATUS_FAIL_HSM_IO, "Bad sign_tx_reply %s",
|
|
|
|
tal_hex(tmpctx, msg));
|
|
|
|
|
|
|
|
/* You can tell this has been a problem before, since there's a debug
|
|
|
|
* message here: */
|
2019-09-08 18:39:26 +02:00
|
|
|
status_debug("signature %s on tx %s using key %s",
|
2019-05-31 23:46:04 +02:00
|
|
|
type_to_string(tmpctx, struct bitcoin_signature, sig),
|
|
|
|
type_to_string(tmpctx, struct bitcoin_tx, *tx),
|
|
|
|
type_to_string(tmpctx, struct pubkey,
|
|
|
|
&state->our_funding_pubkey));
|
|
|
|
|
|
|
|
/* Now we give our peer the signature for their first commitment
|
|
|
|
* transaction. */
|
|
|
|
msg = towire_funding_created(state, &state->channel_id,
|
2021-10-13 05:45:36 +02:00
|
|
|
&state->funding.txid,
|
|
|
|
state->funding.n,
|
2019-05-31 23:46:04 +02:00
|
|
|
&sig->s);
|
2022-01-08 14:23:29 +01:00
|
|
|
peer_write(state->pps, msg);
|
2019-05-31 23:46:04 +02:00
|
|
|
|
|
|
|
/* BOLT #2:
|
|
|
|
*
|
|
|
|
* ### The `funding_signed` Message
|
|
|
|
*
|
|
|
|
* This message gives the funder the signature it needs for the first
|
|
|
|
* commitment transaction, so it can broadcast the transaction knowing
|
|
|
|
* that funds can be redeemed, if need be.
|
|
|
|
*/
|
|
|
|
peer_billboard(false,
|
|
|
|
"Funding channel: create first tx, now waiting for their signature");
|
|
|
|
|
|
|
|
/* Now they send us their signature for that first commitment
|
2021-12-28 00:24:09 +01:00
|
|
|
* transaction. Note that errors may refer to the temporary channel
|
|
|
|
* id (state->channel_id), but success should refer to the new
|
|
|
|
* "cid" */
|
2022-03-22 21:26:29 +01:00
|
|
|
msg = opening_negotiate_msg(tmpctx, state, &cid);
|
2019-05-31 23:46:04 +02:00
|
|
|
if (!msg)
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
sig->sighash_type = SIGHASH_ALL;
|
|
|
|
if (!fromwire_funding_signed(msg, &id_in, &sig->s))
|
2021-02-02 13:49:01 +01:00
|
|
|
peer_failed_err(state->pps, &state->channel_id,
|
|
|
|
"Parsing funding_signed: %s", tal_hex(msg, msg));
|
2019-05-31 23:46:04 +02:00
|
|
|
/* BOLT #2:
|
|
|
|
*
|
|
|
|
* This message introduces the `channel_id` to identify the channel.
|
|
|
|
* It's derived from the funding transaction by combining the
|
|
|
|
* `funding_txid` and the `funding_output_index`, using big-endian
|
|
|
|
* exclusive-OR (i.e. `funding_output_index` alters the last 2
|
|
|
|
* bytes).
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*~ Back in Milan, we chose to allow multiple channels between peers in
|
|
|
|
* the protocol. I insisted that we multiplex these over the same
|
|
|
|
* socket, and (even though I didn't plan on implementing it anytime
|
|
|
|
* soon) that we put it into the first version of the protocol
|
|
|
|
* because it would be painful to add in later.
|
|
|
|
*
|
|
|
|
* My logic seemed sound: we treat new connections as an implication
|
|
|
|
* that the old connection has disconnected, which happens more often
|
|
|
|
* than you'd hope on modern networks. However, supporting multiple
|
|
|
|
* channels via multiple connections would be far easier for us to
|
|
|
|
* support with our (introduced-since) separate daemon model.
|
|
|
|
*
|
|
|
|
* Let this be a lesson: beware premature specification, even if you
|
|
|
|
* suspect "we'll need it later!". */
|
2020-09-09 09:20:53 +02:00
|
|
|
state->channel_id = cid;
|
2019-05-31 23:46:04 +02:00
|
|
|
|
|
|
|
if (!channel_id_eq(&id_in, &state->channel_id))
|
2021-02-02 13:49:01 +01:00
|
|
|
peer_failed_err(state->pps, &id_in,
|
|
|
|
"funding_signed ids don't match: expected %s got %s",
|
|
|
|
type_to_string(msg, struct channel_id,
|
|
|
|
&state->channel_id),
|
|
|
|
type_to_string(msg, struct channel_id, &id_in));
|
2019-05-31 23:46:04 +02:00
|
|
|
|
|
|
|
/* BOLT #2:
|
|
|
|
*
|
|
|
|
* The recipient:
|
2021-02-22 02:57:57 +01:00
|
|
|
* - if `signature` is incorrect OR non-compliant with LOW-S-standard rule...:
|
|
|
|
* - MUST fail the channel
|
2019-05-31 23:46:04 +02:00
|
|
|
*/
|
|
|
|
/* So we create *our* initial commitment transaction, and check the
|
|
|
|
* signature they sent against that. */
|
|
|
|
*tx = initial_channel_tx(state, &wscript, state->channel,
|
|
|
|
&state->first_per_commitment_point[LOCAL],
|
2020-05-07 02:43:34 +02:00
|
|
|
LOCAL, direct_outputs, &err_reason);
|
2019-05-31 23:46:04 +02:00
|
|
|
if (!*tx) {
|
2022-03-22 21:26:29 +01:00
|
|
|
negotiation_failed(state,
|
2019-05-31 23:46:04 +02:00
|
|
|
"Could not meet our fees and reserve: %s", err_reason);
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2022-03-16 20:45:29 +01:00
|
|
|
validate_initial_commitment_signature(HSM_FD, *tx, sig);
|
|
|
|
|
2019-05-31 23:46:04 +02:00
|
|
|
if (!check_tx_sig(*tx, 0, NULL, wscript, &state->their_funding_pubkey, sig)) {
|
2021-02-02 13:49:01 +01:00
|
|
|
peer_failed_err(state->pps, &state->channel_id,
|
2021-09-10 04:14:24 +02:00
|
|
|
"Bad signature %s on tx %s using key %s (channel_type=%s)",
|
2021-02-02 13:49:01 +01:00
|
|
|
type_to_string(tmpctx, struct bitcoin_signature,
|
|
|
|
sig),
|
|
|
|
type_to_string(tmpctx, struct bitcoin_tx, *tx),
|
|
|
|
type_to_string(tmpctx, struct pubkey,
|
2021-09-10 04:14:24 +02:00
|
|
|
&state->their_funding_pubkey),
|
|
|
|
fmt_featurebits(tmpctx,
|
|
|
|
state->channel->type->features));
|
2019-05-31 23:46:04 +02:00
|
|
|
}
|
|
|
|
|
2020-05-28 01:09:39 +02:00
|
|
|
/* We save their sig to our first commitment tx */
|
2020-07-15 04:00:58 +02:00
|
|
|
if (!psbt_input_set_signature((*tx)->psbt, 0,
|
|
|
|
&state->their_funding_pubkey,
|
|
|
|
sig))
|
2020-06-06 21:38:59 +02:00
|
|
|
status_failed(STATUS_FAIL_INTERNAL_ERROR,
|
|
|
|
"Unable to set signature internally");
|
2020-05-28 01:09:39 +02:00
|
|
|
|
2019-05-31 23:46:04 +02:00
|
|
|
peer_billboard(false, "Funding channel: opening negotiation succeeded");
|
|
|
|
|
|
|
|
return true;
|
|
|
|
|
|
|
|
fail:
|
|
|
|
tal_free(wscript);
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2019-06-05 02:26:39 +02:00
|
|
|
static u8 *funder_channel_complete(struct state *state)
|
2019-05-31 23:46:04 +02:00
|
|
|
{
|
2020-05-07 02:43:42 +02:00
|
|
|
/* Remote commitment tx */
|
2019-05-31 23:46:04 +02:00
|
|
|
struct bitcoin_tx *tx;
|
|
|
|
struct bitcoin_signature sig;
|
|
|
|
struct amount_msat local_msat;
|
2020-05-07 02:43:42 +02:00
|
|
|
struct penalty_base *pbase;
|
2019-05-31 23:46:04 +02:00
|
|
|
|
|
|
|
/* Update the billboard about what we're doing*/
|
|
|
|
peer_billboard(false,
|
|
|
|
"Funding channel con't: continuing with funding_txid %s",
|
2021-10-13 05:45:36 +02:00
|
|
|
type_to_string(tmpctx, struct bitcoin_txid, &state->funding.txid));
|
2019-05-31 23:46:04 +02:00
|
|
|
|
|
|
|
/* We recalculate the local_msat from cached values; should
|
|
|
|
* succeed because we checked it earlier */
|
2021-10-13 05:45:36 +02:00
|
|
|
if (!amount_sat_sub_msat(&local_msat, state->funding_sats, state->push_msat))
|
2020-02-13 06:31:04 +01:00
|
|
|
status_failed(STATUS_FAIL_INTERNAL_ERROR,
|
|
|
|
"push_msat %s > funding %s?",
|
|
|
|
type_to_string(tmpctx, struct amount_msat,
|
|
|
|
&state->push_msat),
|
|
|
|
type_to_string(tmpctx, struct amount_sat,
|
2021-10-13 05:45:36 +02:00
|
|
|
&state->funding_sats));
|
2019-05-31 23:46:04 +02:00
|
|
|
|
2020-05-07 02:43:42 +02:00
|
|
|
if (!funder_finalize_channel_setup(state, local_msat, &sig, &tx,
|
|
|
|
&pbase))
|
2019-05-31 23:46:04 +02:00
|
|
|
return NULL;
|
|
|
|
|
2020-08-25 04:12:18 +02:00
|
|
|
return towire_openingd_funder_reply(state,
|
2019-05-31 23:46:04 +02:00
|
|
|
&state->remoteconf,
|
|
|
|
tx,
|
2020-05-07 02:43:42 +02:00
|
|
|
pbase,
|
2019-05-31 23:46:04 +02:00
|
|
|
&sig,
|
|
|
|
&state->their_points.revocation,
|
|
|
|
&state->their_points.payment,
|
|
|
|
&state->their_points.htlc,
|
|
|
|
&state->their_points.delayed_payment,
|
|
|
|
&state->first_per_commitment_point[REMOTE],
|
|
|
|
state->minimum_depth,
|
|
|
|
&state->their_funding_pubkey,
|
2021-10-13 05:45:36 +02:00
|
|
|
&state->funding,
|
2019-05-31 23:46:04 +02:00
|
|
|
state->feerate_per_kw,
|
|
|
|
state->localconf.channel_reserve,
|
2021-09-10 04:14:16 +02:00
|
|
|
state->upfront_shutdown_script[REMOTE],
|
|
|
|
state->channel_type);
|
2019-05-25 02:40:00 +02:00
|
|
|
}
|
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/*~ The peer sent us an `open_channel`, that means we're the fundee. */
|
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 16:10:58 +02:00
|
|
|
static u8 *fundee_channel(struct state *state, const u8 *open_channel_msg)
|
2017-02-21 05:45:29 +01:00
|
|
|
{
|
2017-09-06 03:25:49 +02:00
|
|
|
struct channel_id id_in;
|
2017-03-07 02:07:06 +01:00
|
|
|
struct basepoints theirs;
|
|
|
|
struct pubkey their_funding_pubkey;
|
2018-12-03 00:15:06 +01:00
|
|
|
struct bitcoin_signature theirsig, sig;
|
2018-07-09 13:17:58 +02:00
|
|
|
struct bitcoin_tx *local_commit, *remote_commit;
|
2017-12-18 07:44:10 +01:00
|
|
|
struct bitcoin_blkid chain_hash;
|
2019-11-27 03:44:13 +01:00
|
|
|
u8 *msg;
|
2017-08-28 18:02:01 +02:00
|
|
|
const u8 *wscript;
|
2017-06-27 04:55:01 +02:00
|
|
|
u8 channel_flags;
|
2021-10-13 05:45:36 +02:00
|
|
|
u16 funding_txout;
|
2019-04-03 10:20:36 +02:00
|
|
|
char* err_reason;
|
2020-05-07 02:43:34 +02:00
|
|
|
struct wally_tx_output *direct_outputs[NUM_SIDES];
|
2020-05-07 02:43:42 +02:00
|
|
|
struct penalty_base *pbase;
|
2020-06-22 07:06:03 +02:00
|
|
|
struct tlv_accept_channel_tlvs *accept_tlvs;
|
2022-03-23 00:31:14 +01:00
|
|
|
struct tlv_open_channel_tlvs *open_tlvs;
|
2022-06-08 13:55:47 +02:00
|
|
|
struct amount_sat *reserve;
|
openingd: work harder to intuit OPT_SCID_ALIAS.
option_scid_alias inside a channel_type allows for more private
channels: in particular, it tells the peer that it MUST NOT allow
routing via the real short channel id, and MUST use the alias.
It only makes sense (and is only permitted!) on unannounced channels.
Unfortunately, we didn't set this bit in the channel_type in v12.0
when it was introduced, instead relying on the presence of the feature
bit with the peer. This was fixed in 23.05, but:
1. Prior to 23.05 we didn't allow it to be set at all, and
2. LND has a limited set of features they allow, and this isn't allowed without
option_anchors_zero_fee_htlc_tx.
We could simply drop this channel_type until we merge anchors, *but*
that has nasty privacy implications (you can probe the real channel id).
So, if we don't negotiate anchors (we don't!), we don't set this
channel_type bit even if we want it, and *intuit* it, based on:
1. Is this a non-anchor channel_type?
2. Did we both send channel_type?
3. Is this an unannounced channel?
4. Did both peers announce support for scid aliases?
In addition, while looking at the previous backwards-compat code, I
realized that v23.05 violated the spec and send accept_channel with
OPT_SCID_ALIAS if it intuited it, even if it wasn't offered. Stop
doing this, but allow our peers to.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Fix incompatibility with LND which prevented us opening private channels
Fixes: #6208
2023-06-06 04:30:39 +02:00
|
|
|
bool open_channel_had_channel_type;
|
2017-02-21 05:45:29 +01:00
|
|
|
|
|
|
|
/* BOLT #2:
|
|
|
|
*
|
2018-06-17 12:13:44 +02:00
|
|
|
* The receiving node MUST fail the channel if:
|
|
|
|
*...
|
|
|
|
* - `funding_pubkey`, `revocation_basepoint`, `htlc_basepoint`,
|
|
|
|
* `payment_basepoint`, or `delayed_payment_basepoint` are not valid
|
2020-03-31 00:38:58 +02:00
|
|
|
* secp256k1 pubkeys in compressed format.
|
2017-02-21 05:45:29 +01:00
|
|
|
*/
|
2022-03-23 00:31:14 +01:00
|
|
|
if (!fromwire_open_channel(tmpctx, open_channel_msg, &chain_hash,
|
2019-05-01 00:58:09 +02:00
|
|
|
&state->channel_id,
|
2021-10-13 05:45:36 +02:00
|
|
|
&state->funding_sats,
|
2019-05-01 00:58:09 +02:00
|
|
|
&state->push_msat,
|
|
|
|
&state->remoteconf.dust_limit,
|
|
|
|
&state->remoteconf.max_htlc_value_in_flight,
|
|
|
|
&state->remoteconf.channel_reserve,
|
|
|
|
&state->remoteconf.htlc_minimum,
|
|
|
|
&state->feerate_per_kw,
|
|
|
|
&state->remoteconf.to_self_delay,
|
|
|
|
&state->remoteconf.max_accepted_htlcs,
|
|
|
|
&their_funding_pubkey,
|
|
|
|
&theirs.revocation,
|
|
|
|
&theirs.payment,
|
|
|
|
&theirs.delayed_payment,
|
|
|
|
&theirs.htlc,
|
|
|
|
&state->first_per_commitment_point[REMOTE],
|
|
|
|
&channel_flags,
|
2022-03-23 00:31:14 +01:00
|
|
|
&open_tlvs))
|
2021-02-02 13:49:01 +01:00
|
|
|
peer_failed_err(state->pps,
|
|
|
|
&state->channel_id,
|
|
|
|
"Parsing open_channel %s", tal_hex(tmpctx, open_channel_msg));
|
2021-02-19 05:22:02 +01:00
|
|
|
set_remote_upfront_shutdown(state, open_tlvs->upfront_shutdown_script);
|
2017-02-21 05:45:29 +01:00
|
|
|
|
2021-09-10 04:14:24 +02:00
|
|
|
/* BOLT #2:
|
2021-09-10 04:14:23 +02:00
|
|
|
* The receiving node MUST fail the channel if:
|
|
|
|
*...
|
2022-09-10 04:10:31 +02:00
|
|
|
* - It supports `channel_type` and `channel_type` was set:
|
|
|
|
* - if `type` is not suitable.
|
|
|
|
* - if `type` includes `option_zeroconf` and it does not trust the sender to open an unconfirmed channel.
|
2021-09-10 04:14:23 +02:00
|
|
|
*/
|
2021-09-10 04:14:23 +02:00
|
|
|
if (open_tlvs->channel_type) {
|
openingd: work harder to intuit OPT_SCID_ALIAS.
option_scid_alias inside a channel_type allows for more private
channels: in particular, it tells the peer that it MUST NOT allow
routing via the real short channel id, and MUST use the alias.
It only makes sense (and is only permitted!) on unannounced channels.
Unfortunately, we didn't set this bit in the channel_type in v12.0
when it was introduced, instead relying on the presence of the feature
bit with the peer. This was fixed in 23.05, but:
1. Prior to 23.05 we didn't allow it to be set at all, and
2. LND has a limited set of features they allow, and this isn't allowed without
option_anchors_zero_fee_htlc_tx.
We could simply drop this channel_type until we merge anchors, *but*
that has nasty privacy implications (you can probe the real channel id).
So, if we don't negotiate anchors (we don't!), we don't set this
channel_type bit even if we want it, and *intuit* it, based on:
1. Is this a non-anchor channel_type?
2. Did we both send channel_type?
3. Is this an unannounced channel?
4. Did both peers announce support for scid aliases?
In addition, while looking at the previous backwards-compat code, I
realized that v23.05 violated the spec and send accept_channel with
OPT_SCID_ALIAS if it intuited it, even if it wasn't offered. Stop
doing this, but allow our peers to.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Fix incompatibility with LND which prevented us opening private channels
Fixes: #6208
2023-06-06 04:30:39 +02:00
|
|
|
open_channel_had_channel_type = true;
|
2023-08-18 10:36:19 +02:00
|
|
|
state->channel_type = channel_type_accept(
|
|
|
|
state, open_tlvs->channel_type, state->our_features,
|
|
|
|
state->their_features);
|
2021-09-10 04:14:23 +02:00
|
|
|
if (!state->channel_type) {
|
2022-03-22 21:26:29 +01:00
|
|
|
negotiation_failed(state,
|
2021-09-10 04:14:23 +02:00
|
|
|
"Did not support channel_type %s",
|
|
|
|
fmt_featurebits(tmpctx,
|
|
|
|
open_tlvs->channel_type));
|
|
|
|
return NULL;
|
|
|
|
}
|
openingd: work harder to intuit OPT_SCID_ALIAS.
option_scid_alias inside a channel_type allows for more private
channels: in particular, it tells the peer that it MUST NOT allow
routing via the real short channel id, and MUST use the alias.
It only makes sense (and is only permitted!) on unannounced channels.
Unfortunately, we didn't set this bit in the channel_type in v12.0
when it was introduced, instead relying on the presence of the feature
bit with the peer. This was fixed in 23.05, but:
1. Prior to 23.05 we didn't allow it to be set at all, and
2. LND has a limited set of features they allow, and this isn't allowed without
option_anchors_zero_fee_htlc_tx.
We could simply drop this channel_type until we merge anchors, *but*
that has nasty privacy implications (you can probe the real channel id).
So, if we don't negotiate anchors (we don't!), we don't set this
channel_type bit even if we want it, and *intuit* it, based on:
1. Is this a non-anchor channel_type?
2. Did we both send channel_type?
3. Is this an unannounced channel?
4. Did both peers announce support for scid aliases?
In addition, while looking at the previous backwards-compat code, I
realized that v23.05 violated the spec and send accept_channel with
OPT_SCID_ALIAS if it intuited it, even if it wasn't offered. Stop
doing this, but allow our peers to.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Fix incompatibility with LND which prevented us opening private channels
Fixes: #6208
2023-06-06 04:30:39 +02:00
|
|
|
} else {
|
|
|
|
open_channel_had_channel_type = false;
|
2021-09-10 04:14:23 +02:00
|
|
|
state->channel_type
|
|
|
|
= default_channel_type(state,
|
|
|
|
state->our_features,
|
|
|
|
state->their_features);
|
openingd: work harder to intuit OPT_SCID_ALIAS.
option_scid_alias inside a channel_type allows for more private
channels: in particular, it tells the peer that it MUST NOT allow
routing via the real short channel id, and MUST use the alias.
It only makes sense (and is only permitted!) on unannounced channels.
Unfortunately, we didn't set this bit in the channel_type in v12.0
when it was introduced, instead relying on the presence of the feature
bit with the peer. This was fixed in 23.05, but:
1. Prior to 23.05 we didn't allow it to be set at all, and
2. LND has a limited set of features they allow, and this isn't allowed without
option_anchors_zero_fee_htlc_tx.
We could simply drop this channel_type until we merge anchors, *but*
that has nasty privacy implications (you can probe the real channel id).
So, if we don't negotiate anchors (we don't!), we don't set this
channel_type bit even if we want it, and *intuit* it, based on:
1. Is this a non-anchor channel_type?
2. Did we both send channel_type?
3. Is this an unannounced channel?
4. Did both peers announce support for scid aliases?
In addition, while looking at the previous backwards-compat code, I
realized that v23.05 violated the spec and send accept_channel with
OPT_SCID_ALIAS if it intuited it, even if it wasn't offered. Stop
doing this, but allow our peers to.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Fix incompatibility with LND which prevented us opening private channels
Fixes: #6208
2023-06-06 04:30:39 +02:00
|
|
|
}
|
2021-09-10 04:14:23 +02:00
|
|
|
|
2017-03-29 12:54:15 +02:00
|
|
|
/* BOLT #2:
|
|
|
|
*
|
2018-09-20 22:13:53 +02:00
|
|
|
* The receiving node MUST fail the channel if:
|
|
|
|
* - the `chain_hash` value is set to a hash of a chain
|
|
|
|
* that is unknown to the receiver.
|
2017-03-29 12:54:15 +02:00
|
|
|
*/
|
2019-11-20 02:55:35 +01:00
|
|
|
if (!bitcoin_blkid_eq(&chain_hash, &chainparams->genesis_blockhash)) {
|
2022-03-22 21:26:29 +01:00
|
|
|
negotiation_failed(state,
|
2017-12-06 04:22:35 +01:00
|
|
|
"Unknown chain-hash %s",
|
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 16:10:58 +02:00
|
|
|
type_to_string(tmpctx,
|
2017-12-18 07:44:10 +01:00
|
|
|
struct bitcoin_blkid,
|
2017-12-06 04:22:35 +01:00
|
|
|
&chain_hash));
|
2018-08-09 02:25:29 +02:00
|
|
|
return NULL;
|
2017-03-29 12:54:15 +02:00
|
|
|
}
|
|
|
|
|
2020-04-03 02:03:55 +02:00
|
|
|
/* BOLT #2:
|
2017-02-21 05:45:29 +01:00
|
|
|
*
|
2020-04-03 02:03:55 +02:00
|
|
|
* The receiving node MUST fail the channel if:
|
|
|
|
*...
|
|
|
|
* - `funding_satoshis` is greater than or equal to 2^24 and the receiver does not support
|
|
|
|
* `option_support_large_channel`. */
|
|
|
|
/* We choose to require *negotiation*, not just support! */
|
2020-04-03 02:03:59 +02:00
|
|
|
if (!feature_negotiated(state->our_features, state->their_features,
|
|
|
|
OPT_LARGE_CHANNELS)
|
2021-10-13 05:45:36 +02:00
|
|
|
&& amount_sat_greater(state->funding_sats, chainparams->max_funding)) {
|
2022-03-22 21:26:29 +01:00
|
|
|
negotiation_failed(state,
|
2019-02-21 04:45:54 +01:00
|
|
|
"funding_satoshis %s too large",
|
|
|
|
type_to_string(tmpctx, struct amount_sat,
|
2021-10-13 05:45:36 +02:00
|
|
|
&state->funding_sats));
|
2018-08-09 02:25:29 +02:00
|
|
|
return NULL;
|
|
|
|
}
|
2017-02-21 05:45:29 +01:00
|
|
|
|
|
|
|
/* BOLT #2:
|
|
|
|
*
|
2018-06-17 12:13:44 +02:00
|
|
|
* The receiving node MUST fail the channel if:
|
2018-09-20 22:13:53 +02:00
|
|
|
* ...
|
2018-06-17 12:13:44 +02:00
|
|
|
* - `push_msat` is greater than `funding_satoshis` * 1000.
|
2017-02-21 05:45:29 +01:00
|
|
|
*/
|
2021-10-13 05:45:36 +02:00
|
|
|
if (amount_msat_greater_sat(state->push_msat, state->funding_sats)) {
|
2021-02-02 13:49:01 +01:00
|
|
|
peer_failed_err(state->pps, &state->channel_id,
|
|
|
|
"Their push_msat %s"
|
|
|
|
" would be too large for funding_satoshis %s",
|
|
|
|
type_to_string(tmpctx, struct amount_msat,
|
|
|
|
&state->push_msat),
|
|
|
|
type_to_string(tmpctx, struct amount_sat,
|
2021-10-13 05:45:36 +02:00
|
|
|
&state->funding_sats));
|
2018-08-09 02:25:29 +02:00
|
|
|
return NULL;
|
|
|
|
}
|
2017-02-21 05:45:29 +01:00
|
|
|
|
2017-03-02 13:21:49 +01:00
|
|
|
/* BOLT #2:
|
2017-02-24 06:52:56 +01:00
|
|
|
*
|
2018-06-17 12:13:44 +02:00
|
|
|
* The receiving node MUST fail the channel if:
|
|
|
|
*...
|
|
|
|
* - it considers `feerate_per_kw` too small for timely processing or
|
|
|
|
* unreasonably large.
|
2017-02-24 06:52:56 +01:00
|
|
|
*/
|
2018-08-09 02:25:29 +02:00
|
|
|
if (state->feerate_per_kw < state->min_feerate) {
|
2022-03-22 21:26:29 +01:00
|
|
|
negotiation_failed(state,
|
2017-12-06 04:22:35 +01:00
|
|
|
"feerate_per_kw %u below minimum %u",
|
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 16:10:58 +02:00
|
|
|
state->feerate_per_kw, state->min_feerate);
|
2018-08-09 02:25:29 +02:00
|
|
|
return NULL;
|
|
|
|
}
|
2017-02-24 06:52:56 +01:00
|
|
|
|
2018-08-09 02:25:29 +02:00
|
|
|
if (state->feerate_per_kw > state->max_feerate) {
|
2022-03-22 21:26:29 +01:00
|
|
|
negotiation_failed(state,
|
2017-12-06 04:22:35 +01:00
|
|
|
"feerate_per_kw %u above maximum %u",
|
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 16:10:58 +02:00
|
|
|
state->feerate_per_kw, state->max_feerate);
|
2018-08-09 02:25:29 +02:00
|
|
|
return NULL;
|
|
|
|
}
|
2017-02-24 06:52:56 +01:00
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* This reserves 1% of the channel (rounded up) */
|
2020-10-20 02:04:13 +02:00
|
|
|
set_reserve(state, state->remoteconf.dust_limit);
|
2018-03-18 05:41:26 +01:00
|
|
|
|
2022-06-09 17:04:43 +02:00
|
|
|
/* Pending proposal to remove these limits. */
|
2018-06-28 04:01:21 +02:00
|
|
|
/* BOLT #2:
|
2018-03-18 05:41:26 +01:00
|
|
|
*
|
|
|
|
* The sender:
|
|
|
|
*...
|
|
|
|
* - MUST set `channel_reserve_satoshis` greater than or equal to
|
|
|
|
* `dust_limit_satoshis` from the `open_channel` message.
|
2018-03-18 05:41:30 +01:00
|
|
|
* - MUST set `dust_limit_satoshis` less than or equal to
|
2018-03-18 05:41:26 +01:00
|
|
|
* `channel_reserve_satoshis` from the `open_channel` message.
|
|
|
|
*/
|
2022-06-24 12:58:26 +02:00
|
|
|
if (!state->allowdustreserve &&
|
|
|
|
amount_sat_greater(state->remoteconf.dust_limit,
|
2019-02-21 04:45:54 +01:00
|
|
|
state->localconf.channel_reserve)) {
|
2022-03-22 21:26:29 +01:00
|
|
|
negotiation_failed(state,
|
2019-02-21 04:45:54 +01:00
|
|
|
"Our channel reserve %s"
|
|
|
|
" would be below their dust %s",
|
|
|
|
type_to_string(tmpctx, struct amount_sat,
|
|
|
|
&state->localconf.channel_reserve),
|
|
|
|
type_to_string(tmpctx, struct amount_sat,
|
|
|
|
&state->remoteconf.dust_limit));
|
2018-08-09 02:25:29 +02:00
|
|
|
return NULL;
|
|
|
|
}
|
2018-03-18 05:41:26 +01:00
|
|
|
|
2019-09-09 18:11:24 +02:00
|
|
|
/* These checks are the same whether we're opener or accepter... */
|
2021-10-13 05:45:36 +02:00
|
|
|
if (!check_config_bounds(tmpctx, state->funding_sats,
|
2020-09-09 09:20:53 +02:00
|
|
|
state->feerate_per_kw,
|
|
|
|
state->max_to_self_delay,
|
|
|
|
state->min_effective_htlc_capacity,
|
|
|
|
&state->remoteconf,
|
|
|
|
&state->localconf,
|
2023-06-26 01:18:21 +02:00
|
|
|
feature_negotiated(state->our_features,
|
|
|
|
state->their_features,
|
|
|
|
OPT_ANCHOR_OUTPUTS),
|
|
|
|
feature_negotiated(state->our_features,
|
|
|
|
state->their_features,
|
|
|
|
OPT_ANCHORS_ZERO_FEE_HTLC_TX),
|
2020-09-09 09:20:53 +02:00
|
|
|
&err_reason)) {
|
2022-03-22 21:26:29 +01:00
|
|
|
negotiation_failed(state, "%s", err_reason);
|
2018-08-09 02:25:29 +02:00
|
|
|
return NULL;
|
2020-09-09 09:20:53 +02:00
|
|
|
}
|
2017-02-21 05:45:29 +01:00
|
|
|
|
2019-05-20 07:05:24 +02:00
|
|
|
/* Check with lightningd that we can accept this? In particular,
|
|
|
|
* if we have an existing channel, we don't support it. */
|
2020-08-25 04:12:18 +02:00
|
|
|
msg = towire_openingd_got_offer(NULL,
|
2021-10-13 05:45:36 +02:00
|
|
|
state->funding_sats,
|
2019-05-20 07:05:24 +02:00
|
|
|
state->push_msat,
|
|
|
|
state->remoteconf.dust_limit,
|
|
|
|
state->remoteconf.max_htlc_value_in_flight,
|
|
|
|
state->remoteconf.channel_reserve,
|
|
|
|
state->remoteconf.htlc_minimum,
|
|
|
|
state->feerate_per_kw,
|
|
|
|
state->remoteconf.to_self_delay,
|
|
|
|
state->remoteconf.max_accepted_htlcs,
|
|
|
|
channel_flags,
|
2019-11-27 03:44:13 +01:00
|
|
|
state->upfront_shutdown_script[REMOTE]);
|
2019-05-20 07:05:24 +02:00
|
|
|
wire_sync_write(REQ_FD, take(msg));
|
|
|
|
msg = wire_sync_read(tmpctx, REQ_FD);
|
|
|
|
|
2019-11-27 03:44:13 +01:00
|
|
|
/* We don't allocate off tmpctx, because that's freed inside
|
|
|
|
* opening_negotiate_msg */
|
2020-08-25 04:12:18 +02:00
|
|
|
if (!fromwire_openingd_got_offer_reply(state, msg, &err_reason,
|
2022-06-08 13:55:47 +02:00
|
|
|
&state->upfront_shutdown_script[LOCAL],
|
|
|
|
&state->local_upfront_shutdown_wallet_index,
|
2023-08-18 10:17:14 +02:00
|
|
|
&reserve,
|
|
|
|
&state->minimum_depth))
|
2020-08-25 04:12:18 +02:00
|
|
|
master_badmsg(WIRE_OPENINGD_GOT_OFFER_REPLY, msg);
|
2019-05-20 07:05:24 +02:00
|
|
|
|
|
|
|
/* If they give us a reason to reject, do so. */
|
|
|
|
if (err_reason) {
|
2022-03-22 21:26:29 +01:00
|
|
|
negotiation_failed(state, "%s", err_reason);
|
2019-11-27 03:44:13 +01:00
|
|
|
tal_free(err_reason);
|
2019-05-20 07:05:24 +02:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2023-08-18 10:36:19 +02:00
|
|
|
/* BOLT #2:
|
|
|
|
* The receiving node MUST fail the channel if:
|
|
|
|
*...
|
|
|
|
* - if `type` includes `option_zeroconf` and it does not trust the
|
|
|
|
* sender to open an unconfirmed channel.
|
|
|
|
*/
|
2023-08-18 10:17:14 +02:00
|
|
|
if (channel_type_has(state->channel_type, OPT_ZEROCONF) &&
|
|
|
|
state->minimum_depth > 0) {
|
|
|
|
negotiation_failed(
|
|
|
|
state,
|
|
|
|
"You required zeroconf, but you're not on our allowlist");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2019-11-27 03:44:13 +01:00
|
|
|
if (!state->upfront_shutdown_script[LOCAL])
|
2020-12-15 19:28:04 +01:00
|
|
|
state->upfront_shutdown_script[LOCAL]
|
|
|
|
= no_upfront_shutdown_script(state,
|
|
|
|
state->our_features,
|
|
|
|
state->their_features);
|
2019-11-21 01:47:44 +01:00
|
|
|
|
2022-06-08 13:55:47 +02:00
|
|
|
if (reserve != NULL) {
|
|
|
|
set_reserve_absolute(state, state->remoteconf.dust_limit,
|
|
|
|
*reserve);
|
|
|
|
}
|
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* OK, we accept! */
|
2020-06-22 07:06:03 +02:00
|
|
|
accept_tlvs = tlv_accept_channel_tlvs_new(tmpctx);
|
|
|
|
accept_tlvs->upfront_shutdown_script
|
|
|
|
= state->upfront_shutdown_script[LOCAL];
|
2021-09-10 04:14:24 +02:00
|
|
|
/* BOLT #2:
|
2022-05-18 02:58:58 +02:00
|
|
|
* - if `option_channel_type` was negotiated:
|
|
|
|
* - MUST set `channel_type` to the `channel_type` from `open_channel`
|
2021-09-10 04:14:23 +02:00
|
|
|
*/
|
|
|
|
accept_tlvs->channel_type = state->channel_type->features;
|
2020-06-22 07:06:03 +02:00
|
|
|
|
|
|
|
msg = towire_accept_channel(NULL, &state->channel_id,
|
2019-02-21 04:45:55 +01:00
|
|
|
state->localconf.dust_limit,
|
|
|
|
state->localconf.max_htlc_value_in_flight,
|
|
|
|
state->localconf.channel_reserve,
|
|
|
|
state->localconf.htlc_minimum,
|
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 16:10:58 +02:00
|
|
|
state->minimum_depth,
|
2017-02-21 05:49:02 +01:00
|
|
|
state->localconf.to_self_delay,
|
|
|
|
state->localconf.max_accepted_htlcs,
|
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 16:10:58 +02:00
|
|
|
&state->our_funding_pubkey,
|
|
|
|
&state->our_points.revocation,
|
|
|
|
&state->our_points.payment,
|
|
|
|
&state->our_points.delayed_payment,
|
|
|
|
&state->our_points.htlc,
|
2019-05-01 00:58:09 +02:00
|
|
|
&state->first_per_commitment_point[LOCAL],
|
2020-06-22 07:06:03 +02:00
|
|
|
accept_tlvs);
|
2017-02-21 05:45:29 +01:00
|
|
|
|
2022-01-08 14:23:29 +01:00
|
|
|
peer_write(state->pps, take(msg));
|
2017-02-21 05:45:29 +01:00
|
|
|
|
2018-02-23 06:53:47 +01:00
|
|
|
peer_billboard(false,
|
|
|
|
"Incoming channel: accepted, now waiting for them to create funding tx");
|
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* This is a loop which handles gossip until we get a non-gossip msg */
|
2022-03-22 21:26:29 +01:00
|
|
|
msg = opening_negotiate_msg(tmpctx, state, NULL);
|
2018-08-09 02:25:29 +02:00
|
|
|
if (!msg)
|
|
|
|
return NULL;
|
2017-02-21 05:45:29 +01:00
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* The message should be "funding_created" which tells us what funding
|
|
|
|
* tx they generated; the sighash type is implied, so we set it here. */
|
2018-12-03 00:15:06 +01:00
|
|
|
theirsig.sighash_type = SIGHASH_ALL;
|
2018-02-20 21:59:09 +01:00
|
|
|
if (!fromwire_funding_created(msg, &id_in,
|
2021-10-13 05:45:36 +02:00
|
|
|
&state->funding.txid,
|
|
|
|
&funding_txout,
|
2018-12-03 00:15:06 +01:00
|
|
|
&theirsig.s))
|
2021-02-02 13:49:01 +01:00
|
|
|
peer_failed_err(state->pps, &state->channel_id,
|
2017-09-06 03:25:49 +02:00
|
|
|
"Parsing funding_created");
|
2021-10-13 05:45:36 +02:00
|
|
|
/* We only allow 16 bits for this on the wire. */
|
|
|
|
state->funding.n = funding_txout;
|
2017-02-21 05:45:29 +01:00
|
|
|
|
|
|
|
/* BOLT #2:
|
|
|
|
*
|
2018-06-17 12:13:44 +02:00
|
|
|
* The `temporary_channel_id` MUST be the same as the
|
|
|
|
* `temporary_channel_id` in the `open_channel` message.
|
|
|
|
*/
|
2018-07-04 07:30:02 +02:00
|
|
|
if (!channel_id_eq(&id_in, &state->channel_id))
|
2021-02-02 13:49:01 +01:00
|
|
|
peer_failed_err(state->pps, &id_in,
|
|
|
|
"funding_created ids don't match: sent %s got %s",
|
|
|
|
type_to_string(msg, struct channel_id,
|
|
|
|
&state->channel_id),
|
|
|
|
type_to_string(msg, struct channel_id, &id_in));
|
2017-02-21 05:45:29 +01:00
|
|
|
|
openingd: work harder to intuit OPT_SCID_ALIAS.
option_scid_alias inside a channel_type allows for more private
channels: in particular, it tells the peer that it MUST NOT allow
routing via the real short channel id, and MUST use the alias.
It only makes sense (and is only permitted!) on unannounced channels.
Unfortunately, we didn't set this bit in the channel_type in v12.0
when it was introduced, instead relying on the presence of the feature
bit with the peer. This was fixed in 23.05, but:
1. Prior to 23.05 we didn't allow it to be set at all, and
2. LND has a limited set of features they allow, and this isn't allowed without
option_anchors_zero_fee_htlc_tx.
We could simply drop this channel_type until we merge anchors, *but*
that has nasty privacy implications (you can probe the real channel id).
So, if we don't negotiate anchors (we don't!), we don't set this
channel_type bit even if we want it, and *intuit* it, based on:
1. Is this a non-anchor channel_type?
2. Did we both send channel_type?
3. Is this an unannounced channel?
4. Did both peers announce support for scid aliases?
In addition, while looking at the previous backwards-compat code, I
realized that v23.05 violated the spec and send accept_channel with
OPT_SCID_ALIAS if it intuited it, even if it wasn't offered. Stop
doing this, but allow our peers to.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Fix incompatibility with LND which prevented us opening private channels
Fixes: #6208
2023-06-06 04:30:39 +02:00
|
|
|
/* Backwards/cross compat hack */
|
|
|
|
if (intuit_scid_alias_type(state, channel_flags,
|
|
|
|
open_channel_had_channel_type)) {
|
|
|
|
channel_type_set_scid_alias(state->channel_type);
|
|
|
|
}
|
|
|
|
|
2021-11-04 18:48:43 +01:00
|
|
|
/*~ Channel is ready; Report the channel parameters to the signer. */
|
|
|
|
msg = towire_hsmd_ready_channel(NULL,
|
|
|
|
false, /* is_outbound */
|
|
|
|
state->funding_sats,
|
|
|
|
state->push_msat,
|
|
|
|
&state->funding.txid,
|
|
|
|
state->funding.n,
|
|
|
|
state->localconf.to_self_delay,
|
|
|
|
state->upfront_shutdown_script[LOCAL],
|
|
|
|
state->local_upfront_shutdown_wallet_index,
|
|
|
|
&theirs,
|
|
|
|
&their_funding_pubkey,
|
|
|
|
state->remoteconf.to_self_delay,
|
|
|
|
state->upfront_shutdown_script[REMOTE],
|
|
|
|
state->channel_type);
|
|
|
|
wire_sync_write(HSM_FD, take(msg));
|
|
|
|
msg = wire_sync_read(tmpctx, HSM_FD);
|
|
|
|
if (!fromwire_hsmd_ready_channel_reply(msg))
|
|
|
|
status_failed(STATUS_FAIL_HSM_IO, "Bad ready_channel_reply %s",
|
|
|
|
tal_hex(tmpctx, msg));
|
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* Now we can create the channel structure. */
|
2017-08-28 18:02:01 +02:00
|
|
|
state->channel = new_initial_channel(state,
|
2020-09-09 09:20:53 +02:00
|
|
|
&state->channel_id,
|
2021-10-13 05:45:36 +02:00
|
|
|
&state->funding,
|
2019-02-26 17:57:19 +01:00
|
|
|
state->minimum_depth,
|
2021-06-22 20:25:59 +02:00
|
|
|
NULL, 0, /* No channel lease */
|
2021-10-13 05:45:36 +02:00
|
|
|
state->funding_sats,
|
2019-02-21 04:45:55 +01:00
|
|
|
state->push_msat,
|
2019-12-12 15:07:53 +01:00
|
|
|
take(new_fee_states(NULL, REMOTE,
|
|
|
|
&state->feerate_per_kw)),
|
2017-08-28 18:02:01 +02:00
|
|
|
&state->localconf,
|
2018-08-09 02:25:29 +02:00
|
|
|
&state->remoteconf,
|
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 16:10:58 +02:00
|
|
|
&state->our_points, &theirs,
|
|
|
|
&state->our_funding_pubkey,
|
2017-08-28 18:02:01 +02:00
|
|
|
&their_funding_pubkey,
|
2021-09-10 04:14:16 +02:00
|
|
|
state->channel_type,
|
2021-09-08 02:06:14 +02:00
|
|
|
feature_offered(state->their_features,
|
|
|
|
OPT_LARGE_CHANNELS),
|
2017-08-28 18:02:01 +02:00
|
|
|
REMOTE);
|
2018-12-10 23:35:36 +01:00
|
|
|
/* We don't expect this to fail, but it does do some additional
|
|
|
|
* internal sanity checks. */
|
2017-02-21 05:45:29 +01:00
|
|
|
if (!state->channel)
|
2021-02-02 13:49:01 +01:00
|
|
|
peer_failed_err(state->pps, &state->channel_id,
|
|
|
|
"We could not create channel with given config");
|
2017-02-21 05:45:29 +01:00
|
|
|
|
|
|
|
/* BOLT #2:
|
|
|
|
*
|
2018-06-17 12:13:44 +02:00
|
|
|
* The recipient:
|
2021-02-22 02:57:57 +01:00
|
|
|
* - if `signature` is incorrect OR non-compliant with LOW-S-standard
|
|
|
|
* rule...:
|
2022-03-31 11:10:50 +02:00
|
|
|
* - MUST send a `warning` and close the connection, or send an
|
|
|
|
* `error` and fail the channel.
|
2017-02-21 05:45:29 +01:00
|
|
|
*/
|
2018-07-09 13:17:58 +02:00
|
|
|
local_commit = initial_channel_tx(state, &wscript, state->channel,
|
2018-12-10 23:26:32 +01:00
|
|
|
&state->first_per_commitment_point[LOCAL],
|
2020-05-07 02:43:34 +02:00
|
|
|
LOCAL, NULL, &err_reason);
|
2018-12-10 23:35:36 +01:00
|
|
|
/* This shouldn't happen either, AFAICT. */
|
2018-08-09 02:25:29 +02:00
|
|
|
if (!local_commit) {
|
2022-03-22 21:26:29 +01:00
|
|
|
negotiation_failed(state,
|
2019-04-03 10:20:36 +02:00
|
|
|
"Could not meet our fees and reserve: %s", err_reason);
|
2018-08-09 02:25:29 +02:00
|
|
|
return NULL;
|
|
|
|
}
|
2017-02-21 05:45:29 +01:00
|
|
|
|
2022-03-16 20:45:29 +01:00
|
|
|
validate_initial_commitment_signature(HSM_FD, local_commit, &theirsig);
|
|
|
|
|
2018-07-09 13:17:58 +02:00
|
|
|
if (!check_tx_sig(local_commit, 0, NULL, wscript, &their_funding_pubkey,
|
2017-03-29 12:58:15 +02:00
|
|
|
&theirsig)) {
|
2018-12-10 23:35:36 +01:00
|
|
|
/* BOLT #1:
|
|
|
|
*
|
2022-03-31 11:10:50 +02:00
|
|
|
* ### The `error` and `warning` Messages
|
2018-12-10 23:35:36 +01:00
|
|
|
*...
|
|
|
|
* - when failure was caused by an invalid signature check:
|
|
|
|
* - SHOULD include the raw, hex-encoded transaction in reply
|
|
|
|
* to a `funding_created`, `funding_signed`,
|
|
|
|
* `closing_signed`, or `commitment_signed` message.
|
|
|
|
*/
|
|
|
|
/*~ This verbosity is not only useful for our own testing, but
|
|
|
|
* a courtesy to other implementaters whose brains may be so
|
|
|
|
* twisted by coding in Go, Scala and Rust that they can no
|
|
|
|
* longer read C code. */
|
2021-02-02 13:49:01 +01:00
|
|
|
peer_failed_err(state->pps, &state->channel_id,
|
|
|
|
"Bad signature %s on tx %s using key %s",
|
|
|
|
type_to_string(tmpctx, struct bitcoin_signature,
|
|
|
|
&theirsig),
|
|
|
|
type_to_string(tmpctx, struct bitcoin_tx, local_commit),
|
|
|
|
type_to_string(tmpctx, struct pubkey,
|
|
|
|
&their_funding_pubkey));
|
2017-03-29 12:58:15 +02:00
|
|
|
}
|
2017-02-21 05:45:29 +01:00
|
|
|
|
2017-03-02 13:21:49 +01:00
|
|
|
/* BOLT #2:
|
|
|
|
*
|
2018-06-17 12:13:44 +02:00
|
|
|
* This message introduces the `channel_id` to identify the
|
|
|
|
* channel. It's derived from the funding transaction by combining the
|
|
|
|
* `funding_txid` and the `funding_output_index`, using big-endian
|
|
|
|
* exclusive-OR (i.e. `funding_output_index` alters the last 2 bytes).
|
2017-03-02 13:21:49 +01:00
|
|
|
*/
|
2021-10-13 05:45:36 +02:00
|
|
|
derive_channel_id(&state->channel_id, &state->funding);
|
2017-03-02 13:21:49 +01:00
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/*~ We generate the `funding_signed` message here, since we have all
|
|
|
|
* the data and it's only applicable in the fundee case.
|
|
|
|
*
|
|
|
|
* FIXME: Perhaps we should have channeld generate this, so we
|
|
|
|
* can't possibly send before channel committed to disk?
|
|
|
|
*/
|
|
|
|
|
2017-02-21 05:45:29 +01:00
|
|
|
/* BOLT #2:
|
|
|
|
*
|
2018-06-17 12:13:44 +02:00
|
|
|
* ### The `funding_signed` Message
|
2017-02-21 05:45:29 +01:00
|
|
|
*
|
2018-06-17 12:13:44 +02:00
|
|
|
* This message gives the funder the signature it needs for the first
|
2018-06-28 04:01:21 +02:00
|
|
|
* commitment transaction, so it can broadcast the transaction knowing
|
2018-06-17 12:13:44 +02:00
|
|
|
* that funds can be redeemed, if need be.
|
2017-02-21 05:45:29 +01:00
|
|
|
*/
|
2018-07-09 13:17:58 +02:00
|
|
|
remote_commit = initial_channel_tx(state, &wscript, state->channel,
|
2018-12-10 23:26:32 +01:00
|
|
|
&state->first_per_commitment_point[REMOTE],
|
2020-05-07 02:43:34 +02:00
|
|
|
REMOTE, direct_outputs, &err_reason);
|
2018-08-09 02:25:29 +02:00
|
|
|
if (!remote_commit) {
|
2022-03-22 21:26:29 +01:00
|
|
|
negotiation_failed(state,
|
2019-04-03 10:20:36 +02:00
|
|
|
"Could not meet their fees and reserve: %s", err_reason);
|
2018-08-09 02:25:29 +02:00
|
|
|
return NULL;
|
|
|
|
}
|
2018-03-18 05:41:32 +01:00
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* Make HSM sign it */
|
2021-12-15 02:37:35 +01:00
|
|
|
struct simple_htlc **htlcs = tal_arr(tmpctx, struct simple_htlc *, 0);
|
|
|
|
u32 feerate = 0; // unused since there are no htlcs
|
|
|
|
u64 commit_num = 0;
|
2020-08-25 03:55:38 +02:00
|
|
|
msg = towire_hsmd_sign_remote_commitment_tx(NULL,
|
2018-07-23 04:23:03 +02:00
|
|
|
remote_commit,
|
|
|
|
&state->channel->funding_pubkey[REMOTE],
|
2020-02-04 01:10:43 +01:00
|
|
|
&state->first_per_commitment_point[REMOTE],
|
2021-09-09 07:25:23 +02:00
|
|
|
channel_has(state->channel,
|
2021-12-15 02:37:35 +01:00
|
|
|
OPT_STATIC_REMOTEKEY),
|
|
|
|
commit_num,
|
|
|
|
(const struct simple_htlc **) htlcs,
|
|
|
|
feerate);
|
2018-07-23 04:23:03 +02:00
|
|
|
|
|
|
|
wire_sync_write(HSM_FD, take(msg));
|
|
|
|
msg = wire_sync_read(tmpctx, HSM_FD);
|
2020-08-25 03:55:38 +02:00
|
|
|
if (!fromwire_hsmd_sign_tx_reply(msg, &sig))
|
2018-07-23 04:23:03 +02:00
|
|
|
status_failed(STATUS_FAIL_HSM_IO,
|
|
|
|
"Bad sign_tx_reply %s", tal_hex(tmpctx, msg));
|
2017-02-21 05:45:29 +01:00
|
|
|
|
2017-05-24 12:10:17 +02:00
|
|
|
/* We don't send this ourselves: channeld does, because master needs
|
|
|
|
* to save state to disk before doing so. */
|
2018-12-03 00:15:06 +01:00
|
|
|
assert(sig.sighash_type == SIGHASH_ALL);
|
|
|
|
msg = towire_funding_signed(state, &state->channel_id, &sig.s);
|
2017-05-23 13:07:42 +02:00
|
|
|
|
2020-05-07 02:43:42 +02:00
|
|
|
if (direct_outputs[LOCAL] != NULL)
|
|
|
|
pbase = penalty_base_new(tmpctx, 0, remote_commit,
|
|
|
|
direct_outputs[LOCAL]);
|
|
|
|
else
|
|
|
|
pbase = NULL;
|
|
|
|
|
2020-08-25 04:12:18 +02:00
|
|
|
return towire_openingd_fundee(state,
|
2018-08-09 02:25:29 +02:00
|
|
|
&state->remoteconf,
|
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 16:10:58 +02:00
|
|
|
local_commit,
|
2020-05-07 02:43:42 +02:00
|
|
|
pbase,
|
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 16:10:58 +02:00
|
|
|
&theirsig,
|
|
|
|
&theirs.revocation,
|
|
|
|
&theirs.payment,
|
|
|
|
&theirs.htlc,
|
|
|
|
&theirs.delayed_payment,
|
2018-12-10 23:26:32 +01:00
|
|
|
&state->first_per_commitment_point[REMOTE],
|
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 16:10:58 +02:00
|
|
|
&their_funding_pubkey,
|
2021-10-13 05:45:36 +02:00
|
|
|
&state->funding,
|
|
|
|
state->funding_sats,
|
2019-02-21 04:45:55 +01:00
|
|
|
state->push_msat,
|
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 16:10:58 +02:00
|
|
|
channel_flags,
|
|
|
|
state->feerate_per_kw,
|
|
|
|
msg,
|
2019-05-01 00:58:09 +02:00
|
|
|
state->localconf.channel_reserve,
|
2019-11-27 03:44:13 +01:00
|
|
|
state->upfront_shutdown_script[LOCAL],
|
2021-09-10 04:14:16 +02:00
|
|
|
state->upfront_shutdown_script[REMOTE],
|
|
|
|
state->channel_type);
|
2017-02-21 05:45:29 +01:00
|
|
|
}
|
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/*~ Standard "peer sent a message, handle it" demuxer. Though it really only
|
|
|
|
* handles one message, we use the standard form as principle of least
|
|
|
|
* surprise. */
|
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 16:10:58 +02:00
|
|
|
static u8 *handle_peer_in(struct state *state)
|
2017-02-21 05:45:29 +01:00
|
|
|
{
|
2022-01-08 14:23:29 +01:00
|
|
|
u8 *msg = peer_read(tmpctx, state->pps);
|
2020-08-31 03:13:25 +02:00
|
|
|
enum peer_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 16:10:58 +02:00
|
|
|
struct channel_id channel_id;
|
2021-06-15 07:07:15 +02:00
|
|
|
bool extracted;
|
2018-04-25 12:55:34 +02:00
|
|
|
|
2019-08-05 06:48:05 +02:00
|
|
|
if (t == WIRE_OPEN_CHANNEL)
|
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 16:10:58 +02:00
|
|
|
return fundee_channel(state, msg);
|
|
|
|
|
2022-01-29 04:33:05 +01:00
|
|
|
/* Handles error cases. */
|
|
|
|
if (handle_peer_error(state->pps, &state->channel_id, msg))
|
2019-08-05 06:48:05 +02:00
|
|
|
return NULL;
|
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 16:10:58 +02:00
|
|
|
|
2021-06-15 07:07:15 +02:00
|
|
|
extracted = extract_channel_id(msg, &channel_id);
|
|
|
|
|
2022-01-08 14:23:29 +01:00
|
|
|
peer_write(state->pps,
|
2021-06-15 07:07:15 +02:00
|
|
|
take(towire_warningfmt(NULL,
|
|
|
|
extracted ? &channel_id : NULL,
|
|
|
|
"Unexpected message %s: %s",
|
|
|
|
peer_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 16:10:58 +02:00
|
|
|
|
|
|
|
/* FIXME: We don't actually want master to try to send an
|
|
|
|
* error, since peer is transient. This is a hack.
|
|
|
|
*/
|
2020-08-31 03:13:25 +02:00
|
|
|
status_broken("Unexpected message %s", peer_wire_name(t));
|
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 16:10:58 +02:00
|
|
|
peer_failed_connection_lost();
|
|
|
|
}
|
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* Memory leak detection is DEVELOPER-only because we go to great lengths to
|
|
|
|
* record the backtrace when allocations occur: without that, the leak
|
|
|
|
* detection tends to be useless for diagnosing where the leak came from, but
|
|
|
|
* it has significant overhead. */
|
2018-11-22 03:17:29 +01:00
|
|
|
#if DEVELOPER
|
|
|
|
static void handle_dev_memleak(struct state *state, const u8 *msg)
|
|
|
|
{
|
|
|
|
struct htable *memtable;
|
|
|
|
bool found_leak;
|
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* Populate a hash table with all our allocations (except msg, which
|
|
|
|
* is in use right now). */
|
2022-09-16 05:15:03 +02:00
|
|
|
memtable = memleak_start(tmpctx);
|
|
|
|
memleak_ptr(memtable, msg);
|
2018-11-22 03:17:29 +01:00
|
|
|
|
|
|
|
/* Now delete state and things it has pointers to. */
|
2022-09-16 05:14:39 +02:00
|
|
|
memleak_scan_obj(memtable, state);
|
2018-11-22 03:17:29 +01:00
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* If there's anything left, dump it to logs, and return true. */
|
2021-09-06 14:39:27 +02:00
|
|
|
found_leak = dump_memleak(memtable, memleak_status_broken);
|
2018-11-22 03:17:29 +01:00
|
|
|
wire_sync_write(REQ_FD,
|
2020-08-25 04:12:18 +02:00
|
|
|
take(towire_openingd_dev_memleak_reply(NULL,
|
2018-11-22 03:17:29 +01:00
|
|
|
found_leak)));
|
|
|
|
}
|
2021-07-13 23:04:30 +02:00
|
|
|
#endif /* DEVELOPER */
|
2019-12-04 16:53:12 +01:00
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* Standard lightningd-fd-is-ready-to-read demux code. Again, we could hang
|
|
|
|
* here, but if we can't trust our parent, who can we trust? */
|
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 16:10:58 +02:00
|
|
|
static u8 *handle_master_in(struct state *state)
|
|
|
|
{
|
2018-08-24 09:06:59 +02:00
|
|
|
u8 *msg = wire_sync_read(tmpctx, REQ_FD);
|
2020-08-25 04:12:18 +02:00
|
|
|
enum openingd_wire t = fromwire_peektype(msg);
|
2019-11-27 03:44:13 +01:00
|
|
|
u8 channel_flags;
|
2019-05-25 02:40:00 +02:00
|
|
|
struct bitcoin_txid funding_txid;
|
2019-05-31 23:37:05 +02:00
|
|
|
u16 funding_txout;
|
2023-06-26 01:11:21 +02:00
|
|
|
u32 nonanchor_feerate, anchor_feerate;
|
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 16:10:58 +02:00
|
|
|
|
|
|
|
switch (t) {
|
2020-08-25 04:12:18 +02:00
|
|
|
case WIRE_OPENINGD_FUNDER_START:
|
2021-10-13 05:45:36 +02:00
|
|
|
if (!fromwire_openingd_funder_start(state, msg,
|
|
|
|
&state->funding_sats,
|
|
|
|
&state->push_msat,
|
|
|
|
&state->upfront_shutdown_script[LOCAL],
|
2021-11-04 18:48:43 +01:00
|
|
|
&state->local_upfront_shutdown_wallet_index,
|
2023-06-26 01:11:21 +02:00
|
|
|
&nonanchor_feerate,
|
|
|
|
&anchor_feerate,
|
2022-03-22 21:27:30 +01:00
|
|
|
&state->channel_id,
|
2022-06-09 13:34:33 +02:00
|
|
|
&channel_flags,
|
|
|
|
&state->reserve))
|
2020-08-25 04:12:18 +02:00
|
|
|
master_badmsg(WIRE_OPENINGD_FUNDER_START, msg);
|
2023-06-26 01:11:21 +02:00
|
|
|
msg = funder_channel_start(state, channel_flags, nonanchor_feerate, anchor_feerate);
|
2019-05-22 01:51:52 +02:00
|
|
|
|
|
|
|
/* We want to keep openingd alive, since we're not done yet */
|
2019-08-29 01:09:10 +02:00
|
|
|
if (msg)
|
|
|
|
wire_sync_write(REQ_FD, take(msg));
|
2019-05-22 01:51:52 +02:00
|
|
|
return NULL;
|
2020-08-25 04:12:18 +02:00
|
|
|
case WIRE_OPENINGD_FUNDER_COMPLETE:
|
2021-09-10 04:14:16 +02:00
|
|
|
if (!fromwire_openingd_funder_complete(state, msg,
|
|
|
|
&funding_txid,
|
|
|
|
&funding_txout,
|
|
|
|
&state->channel_type))
|
2020-08-25 04:12:18 +02:00
|
|
|
master_badmsg(WIRE_OPENINGD_FUNDER_COMPLETE, msg);
|
2021-10-13 05:45:36 +02:00
|
|
|
state->funding.txid = funding_txid;
|
|
|
|
state->funding.n = funding_txout;
|
2019-06-05 02:26:39 +02:00
|
|
|
return funder_channel_complete(state);
|
2020-08-25 04:12:18 +02:00
|
|
|
case WIRE_OPENINGD_FUNDER_CANCEL:
|
2019-05-31 23:57:04 +02:00
|
|
|
/* We're aborting this, simple */
|
2020-08-25 04:12:18 +02:00
|
|
|
if (!fromwire_openingd_funder_cancel(msg))
|
|
|
|
master_badmsg(WIRE_OPENINGD_FUNDER_CANCEL, msg);
|
2019-05-31 23:57:04 +02:00
|
|
|
|
|
|
|
msg = towire_errorfmt(NULL, &state->channel_id, "Channel open canceled by us");
|
2022-01-08 14:23:29 +01:00
|
|
|
peer_write(state->pps, take(msg));
|
2022-03-22 21:26:29 +01:00
|
|
|
negotiation_aborted(state, "Channel open canceled by RPC");
|
2019-05-31 23:57:04 +02:00
|
|
|
return NULL;
|
2020-08-25 04:12:18 +02:00
|
|
|
case WIRE_OPENINGD_DEV_MEMLEAK:
|
2018-11-22 03:17:29 +01:00
|
|
|
#if DEVELOPER
|
|
|
|
handle_dev_memleak(state, msg);
|
|
|
|
return NULL;
|
|
|
|
#endif
|
2020-08-25 04:12:18 +02:00
|
|
|
case WIRE_OPENINGD_DEV_MEMLEAK_REPLY:
|
|
|
|
case WIRE_OPENINGD_INIT:
|
|
|
|
case WIRE_OPENINGD_FUNDER_REPLY:
|
|
|
|
case WIRE_OPENINGD_FUNDER_START_REPLY:
|
|
|
|
case WIRE_OPENINGD_FUNDEE:
|
2022-03-22 21:26:29 +01:00
|
|
|
case WIRE_OPENINGD_FAILED:
|
2020-08-25 04:12:18 +02:00
|
|
|
case WIRE_OPENINGD_GOT_OFFER:
|
|
|
|
case WIRE_OPENINGD_GOT_OFFER_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 16:10:58 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
status_failed(STATUS_FAIL_MASTER_IO,
|
|
|
|
"Unknown msg %s", tal_hex(tmpctx, msg));
|
|
|
|
}
|
|
|
|
|
|
|
|
int main(int argc, char *argv[])
|
|
|
|
{
|
|
|
|
setup_locale();
|
|
|
|
|
2021-06-03 05:23:05 +02:00
|
|
|
u8 *msg;
|
2022-01-29 04:33:05 +01:00
|
|
|
struct pollfd pollfd[2];
|
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 16:10:58 +02:00
|
|
|
struct state *state = tal(NULL, struct state);
|
2018-07-23 04:23:03 +02:00
|
|
|
struct secret *none;
|
2019-11-01 18:01:54 +01:00
|
|
|
struct channel_id *force_tmp_channel_id;
|
2017-02-21 05:45:29 +01:00
|
|
|
|
2018-01-08 11:01:09 +01:00
|
|
|
subdaemon_setup(argc, argv);
|
2017-02-21 05:45:29 +01:00
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/*~ This makes status_failed, status_debug etc work synchronously by
|
|
|
|
* writing to REQ_FD */
|
2017-03-19 21:32:44 +01:00
|
|
|
status_setup_sync(REQ_FD);
|
2017-02-21 05:45:29 +01:00
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/*~ The very first thing we read from lightningd is our init 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 16:10:58 +02:00
|
|
|
msg = wire_sync_read(tmpctx, REQ_FD);
|
2020-08-25 04:12:18 +02:00
|
|
|
if (!fromwire_openingd_init(state, msg,
|
2022-06-22 15:31:27 +02:00
|
|
|
&chainparams,
|
|
|
|
&state->our_features,
|
|
|
|
&state->their_features,
|
|
|
|
&state->localconf,
|
|
|
|
&state->max_to_self_delay,
|
|
|
|
&state->min_effective_htlc_capacity,
|
|
|
|
&state->our_points,
|
|
|
|
&state->our_funding_pubkey,
|
|
|
|
&state->minimum_depth,
|
|
|
|
&state->min_feerate, &state->max_feerate,
|
|
|
|
&force_tmp_channel_id,
|
openingd: work harder to intuit OPT_SCID_ALIAS.
option_scid_alias inside a channel_type allows for more private
channels: in particular, it tells the peer that it MUST NOT allow
routing via the real short channel id, and MUST use the alias.
It only makes sense (and is only permitted!) on unannounced channels.
Unfortunately, we didn't set this bit in the channel_type in v12.0
when it was introduced, instead relying on the presence of the feature
bit with the peer. This was fixed in 23.05, but:
1. Prior to 23.05 we didn't allow it to be set at all, and
2. LND has a limited set of features they allow, and this isn't allowed without
option_anchors_zero_fee_htlc_tx.
We could simply drop this channel_type until we merge anchors, *but*
that has nasty privacy implications (you can probe the real channel id).
So, if we don't negotiate anchors (we don't!), we don't set this
channel_type bit even if we want it, and *intuit* it, based on:
1. Is this a non-anchor channel_type?
2. Did we both send channel_type?
3. Is this an unannounced channel?
4. Did both peers announce support for scid aliases?
In addition, while looking at the previous backwards-compat code, I
realized that v23.05 violated the spec and send accept_channel with
OPT_SCID_ALIAS if it intuited it, even if it wasn't offered. Stop
doing this, but allow our peers to.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Fixed: Fix incompatibility with LND which prevented us opening private channels
Fixes: #6208
2023-06-06 04:30:39 +02:00
|
|
|
&state->allowdustreserve))
|
2020-08-25 04:12:18 +02:00
|
|
|
master_badmsg(WIRE_OPENINGD_INIT, msg);
|
2017-09-12 06:55:52 +02:00
|
|
|
|
2019-11-01 18:01:54 +01:00
|
|
|
#if DEVELOPER
|
|
|
|
dev_force_tmp_channel_id = force_tmp_channel_id;
|
|
|
|
#endif
|
|
|
|
|
2022-01-29 04:33:05 +01:00
|
|
|
/* 3 == peer, 4 = hsmd */
|
2022-01-08 14:29:29 +01:00
|
|
|
state->pps = new_per_peer_state(state);
|
2022-01-29 04:33:05 +01:00
|
|
|
per_peer_state_set_fd(state->pps, 3);
|
2019-06-03 20:11:25 +02:00
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/*~ Initially we're not associated with a channel, but
|
|
|
|
* handle_peer_gossip_or_error compares this. */
|
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 16:10:58 +02:00
|
|
|
memset(&state->channel_id, 0, sizeof(state->channel_id));
|
2018-08-09 02:25:29 +02:00
|
|
|
state->channel = NULL;
|
2017-07-11 15:50:10 +02:00
|
|
|
|
2021-09-28 21:03:08 +02:00
|
|
|
/* Default this to zero, we only ever look at the local */
|
|
|
|
state->remoteconf.max_dust_htlc_exposure_msat = AMOUNT_MSAT(0);
|
|
|
|
|
2019-11-27 03:44:13 +01:00
|
|
|
/*~ We set these to NULL, meaning no requirements on shutdown */
|
|
|
|
state->upfront_shutdown_script[LOCAL]
|
|
|
|
= state->upfront_shutdown_script[REMOTE]
|
|
|
|
= NULL;
|
2019-05-01 00:58:09 +02:00
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/*~ We need an initial per-commitment point whether we're funding or
|
|
|
|
* they are, and lightningd has reserved a unique dbid for us already,
|
|
|
|
* so we might as well get the hsm daemon to generate it now. */
|
2018-07-23 04:23:03 +02:00
|
|
|
wire_sync_write(HSM_FD,
|
2020-08-25 03:55:38 +02:00
|
|
|
take(towire_hsmd_get_per_commitment_point(NULL, 0)));
|
2018-07-23 04:23:03 +02:00
|
|
|
msg = wire_sync_read(tmpctx, HSM_FD);
|
2020-08-25 03:55:38 +02:00
|
|
|
if (!fromwire_hsmd_get_per_commitment_point_reply(tmpctx, msg,
|
2018-12-10 23:26:32 +01:00
|
|
|
&state->first_per_commitment_point[LOCAL],
|
2018-07-23 04:23:03 +02:00
|
|
|
&none))
|
|
|
|
status_failed(STATUS_FAIL_HSM_IO,
|
|
|
|
"Bad get_per_commitment_point_reply %s",
|
|
|
|
tal_hex(tmpctx, msg));
|
2018-12-10 23:35:36 +01:00
|
|
|
/*~ The HSM gives us the N-2'th per-commitment secret when we get the
|
|
|
|
* N'th per-commitment point. But since N=0, it won't give us one. */
|
2018-07-23 04:23:03 +02:00
|
|
|
assert(none == NULL);
|
2018-12-10 23:35:36 +01:00
|
|
|
|
|
|
|
/*~ We manually run a little poll() loop here. With only three fds */
|
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 16:10:58 +02:00
|
|
|
pollfd[0].fd = REQ_FD;
|
|
|
|
pollfd[0].events = POLLIN;
|
2022-01-29 04:33:05 +01:00
|
|
|
pollfd[1].fd = state->pps->peer_fd;
|
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 16:10:58 +02:00
|
|
|
pollfd[1].events = POLLIN;
|
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* We exit when we get a conclusion to write to lightningd: either
|
|
|
|
* opening_funder_reply or opening_fundee. */
|
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 16:10:58 +02:00
|
|
|
msg = NULL;
|
|
|
|
while (!msg) {
|
2019-09-22 04:04:43 +02:00
|
|
|
/*~ If we get a signal which aborts the poll() call, valgrind
|
|
|
|
* complains about revents being uninitialized. I'm not sure
|
|
|
|
* that's correct, but it's easy to be sure. */
|
2022-01-29 04:33:05 +01:00
|
|
|
pollfd[0].revents = pollfd[1].revents = 0;
|
2019-09-22 04:04:43 +02:00
|
|
|
|
2022-01-08 14:29:29 +01:00
|
|
|
poll(pollfd, ARRAY_SIZE(pollfd), -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 16:10:58 +02:00
|
|
|
/* Subtle: handle_master_in can do its own poll loop, so
|
|
|
|
* don't try to service more than one fd per loop. */
|
2018-12-10 23:35:36 +01:00
|
|
|
/* First priority: messages from lightningd. */
|
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 16:10:58 +02:00
|
|
|
if (pollfd[0].revents & POLLIN)
|
|
|
|
msg = handle_master_in(state);
|
2018-12-10 23:35:36 +01:00
|
|
|
/* Second priority: messages from peer. */
|
2018-09-17 07:55:30 +02:00
|
|
|
else if (pollfd[1].revents & POLLIN)
|
2022-01-29 04:33:05 +01:00
|
|
|
msg = handle_peer_in(state);
|
2018-09-17 07:55:30 +02:00
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* Since we're the top-level event loop, we clean up */
|
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 16:10:58 +02:00
|
|
|
clean_tmpctx();
|
|
|
|
}
|
2017-02-21 05:45:29 +01:00
|
|
|
|
2022-01-29 04:33:05 +01:00
|
|
|
/*~ Write message and hand back the peer fd. This also means that if
|
|
|
|
* the peer wrote us any messages we didn't read yet, it will simply
|
|
|
|
* be read by the next daemon. */
|
2017-02-24 06:52:56 +01:00
|
|
|
wire_sync_write(REQ_FD, msg);
|
2019-06-03 20:11:25 +02:00
|
|
|
per_peer_state_fdpass_send(REQ_FD, state->pps);
|
2022-01-29 04:33:05 +01:00
|
|
|
status_debug("Sent %s with fd",
|
2020-08-25 04:12:18 +02:00
|
|
|
openingd_wire_name(fromwire_peektype(msg)));
|
2018-12-10 23:35:36 +01:00
|
|
|
|
2022-09-17 00:11:51 +02:00
|
|
|
/* Give master a chance to pass the fd along */
|
|
|
|
sleep(1);
|
|
|
|
|
2018-12-10 23:35:36 +01:00
|
|
|
/* This frees the entire tal tree. */
|
2017-02-21 05:45:29 +01:00
|
|
|
tal_free(state);
|
2018-12-10 23:35:36 +01:00
|
|
|
|
|
|
|
/* This frees up everything else. */
|
2018-03-29 04:06:45 +02:00
|
|
|
daemon_shutdown();
|
2017-02-21 05:45:29 +01:00
|
|
|
return 0;
|
|
|
|
}
|
2018-12-10 23:35:36 +01:00
|
|
|
|
|
|
|
/*~ Note that there are no other source files in openingd: it really is a fairly
|
|
|
|
* straight-line daemon.
|
|
|
|
*
|
|
|
|
* From here the channel is established: lightningd hands the peer off to
|
|
|
|
* channeld/channeld.c which runs the normal channel routine for this peer.
|
|
|
|
*/
|