core-lightning/lightningd/dual_open_control.h

#ifndef LIGHTNING_LIGHTNINGD_DUAL_OPEN_CONTROL_H
#define LIGHTNING_LIGHTNINGD_DUAL_OPEN_CONTROL_H

#include "config.h"
#include <lightningd/subd.h>

struct peer_fd;

bool peer_start_dualopend(struct peer *peer, struct peer_fd *peer_fd,
			  struct channel *channel);

bool peer_restart_dualopend(struct peer *peer,
			    struct peer_fd *peer_fd,
			    struct channel *channel);

void dualopen_tell_depth(struct subd *dualopend,
			 struct channel *channel,
			 const struct bitcoin_txid *txid,
			 u32 depth);

/* Close connection to an unsaved channel */
void channel_unsaved_close_conn(struct channel *channel, const char *why);

void json_add_unsaved_channel(struct json_stream *response,
			      const struct channel *channel);

void channel_update_reserve(struct channel *channel,
			    struct channel_config *their_config,
			    struct amount_sat funding_total);
#endif /* LIGHTNING_LIGHTNINGD_DUAL_OPEN_CONTROL_H */
dual-fund: accepter side implementation on lightningd wherein we add the dual_open_control functions 2020-09-09 12:10:28 +02:00			`#ifndef LIGHTNING_LIGHTNINGD_DUAL_OPEN_CONTROL_H`
			`#define LIGHTNING_LIGHTNINGD_DUAL_OPEN_CONTROL_H`

			`#include "config.h"`
dual-open: handle sigs and channel lockin in dualopend, not channeld This will make it possible to do RBF, since we can re-start the opening process in dualopend while waiting for lock-in. Note the new channel states are being used, DUALOPEND_INIT and DUALOPEND_AWAITING_LOCKIN, to differentiate from openingd/channeld opens 2020-11-24 22:10:19 +01:00			`#include <lightningd/subd.h>`
dual-fund: accepter side implementation on lightningd wherein we add the dual_open_control functions 2020-09-09 12:10:28 +02:00
patch lightningd-peer-fds.patch 2022-01-11 02:13:59 +01:00			`struct peer_fd;`
dual-fund: accepter side implementation on lightningd wherein we add the dual_open_control functions 2020-09-09 12:10:28 +02:00
connectd: hold peer until we're interested. Either because lightningd tells us it wants to talk, or because the peer says something about a channel. We also introduce a behavior change: we disconnect after a failed open. We might want to modify this later, but we it's a side-effect of openingd not holding onto idle connections. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> 2022-03-22 21:27:29 +01:00			`bool peer_start_dualopend(struct peer peer, struct peer_fd peer_fd,`
			`struct channel *channel);`
dual-open: handle sigs and channel lockin in dualopend, not channeld This will make it possible to do RBF, since we can re-start the opening process in dualopend while waiting for lock-in. Note the new channel states are being used, DUALOPEND_INIT and DUALOPEND_AWAITING_LOCKIN, to differentiate from openingd/channeld opens 2020-11-24 22:10:19 +01:00
lightningd: hand fds to connectd, not receive them from connectd. Before this patch: 1. connectd says it's connected (peer_connected) 2. we tell connectd we want to talk about each channel (peer_make_active) 3. connectd gives us an fd for each channel, and we connect it to a subd (peer_active) 4. OR, connectd says it sent something about a channel we didn't tell it about, with an fd (peer_active) Now: 1. connectd says it's connected (peer_connected) 2. we start all appropriate subds and tell connectd to what channels/fds (peer_connect_subd). 3. if connectd says it sent something about a channel we didn't tell it about, we either tell it to hang up (peer_final_msg), or connect a new opening daemon (peer_connect_subd). This is the minimal-size patch, which is why we create socket pairs in so many places to use the existing functions. Many cleanups are possible, since the new flow is so simple. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> 2022-07-18 14:12:18 +02:00			`bool peer_restart_dualopend(struct peer *peer,`
patch lightningd-peer-fds.patch 2022-01-11 02:13:59 +01:00			`struct peer_fd *peer_fd,`
openingd/dualopend: remove send_msg functionality. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> 2021-06-03 05:23:05 +02:00			`struct channel *channel);`
df: reinitialize dual-funding Prior to this, all reconnect logic lived in channeld. If you disconnected before we finished building a funding transaction, that was no big deal. Now, however, we're waiting for the funding to lock in in dualopend, instead of handing straight to channeld to wait. So we need a way to restart dualopend. 2021-01-08 02:05:06 +01:00
dual-open: handle sigs and channel lockin in dualopend, not channeld This will make it possible to do RBF, since we can re-start the opening process in dualopend while waiting for lock-in. Note the new channel states are being used, DUALOPEND_INIT and DUALOPEND_AWAITING_LOCKIN, to differentiate from openingd/channeld opens 2020-11-24 22:10:19 +01:00			`void dualopen_tell_depth(struct subd *dualopend,`
			`struct channel *channel,`
df-rbf: update channel data on depth reached When the funding tx reaches depth, update the channel's data to the "correct" funding transaction info from inflights (if necessary). This will be necessary if: - the transaction has been successfully RBF'd and - the lesser fee transaction is the one successfully mined, OR - the channel is in the process of being RBF'd 2021-01-07 20:03:06 +01:00			`const struct bitcoin_txid *txid,`
dual-open: handle sigs and channel lockin in dualopend, not channeld This will make it possible to do RBF, since we can re-start the opening process in dualopend while waiting for lock-in. Note the new channel states are being used, DUALOPEND_INIT and DUALOPEND_AWAITING_LOCKIN, to differentiate from openingd/channeld opens 2020-11-24 22:10:19 +01:00			`u32 depth);`
df: cleanup error handling on lightningd side Make existing methods understand how unsaved channels work, re-work errors so that we handle everything appropriately 2021-02-16 20:23:53 +01:00
df: rework closing logic Trying to put all the disconnect logic into the same path was a dumb idea. If you asked to reconnect but passed in an 'unsaved' channel, we would not call the 'reconnect' code. Instead, we make a differentiation between "unsaved" channels (ones that we haven't received commitment tx for) and handle the disconnect for these separate from where we want to do a reconnect. 2021-05-11 18:58:00 +02:00			`/* Close connection to an unsaved channel */`
			`void channel_unsaved_close_conn(struct channel channel, const char why);`
connectd: clean up the channel stuffs when we get a reconnect If they've disconnected/reconnected we need to terminate all the inflight stuff, plus go ahead and call 'disconnect' plugin trigger etc. 2021-03-05 19:39:05 +01:00
listpeers: include info on channels that are in-process Channels that we're in negotiation for, but don't have a commitment transaction saved for yet. 2021-02-24 03:29:38 +01:00			`void json_add_unsaved_channel(struct json_stream *response,`
			`const struct channel *channel);`
rbf: update the channel's funding_txid to match what's mined If the peer is offline when we see the funding txid, we don't actually update the channel's info. Here, we move it up to where the scid is set, so that we always update the channel's funding_txid to the correct (mined) information. 2021-05-20 23:50:42 +02:00
			`void channel_update_reserve(struct channel *channel,`
			`struct channel_config *their_config,`
			`struct amount_sat funding_total);`
dual-fund: accepter side implementation on lightningd wherein we add the dual_open_control functions 2020-09-09 12:10:28 +02:00			`#endif /* LIGHTNING_LIGHTNINGD_DUAL_OPEN_CONTROL_H */`