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 per_peer_state;

void peer_start_dualopend(struct peer *peer,
			  struct per_peer_state *pps,
			  const u8 *send_msg);

void peer_restart_dualopend(struct peer *peer,
			    struct per_peer_state *pps,
			    struct channel *channel,
			    const u8 *send_msg);

void dualopen_tell_depth(struct subd *dualopend,
			 struct channel *channel,
			 u32 depth);
#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
			`struct per_peer_state;`

			`void peer_start_dualopend(struct peer *peer,`
			`struct per_peer_state *pps,`
			`const u8 *send_msg);`
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
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			`void peer_restart_dualopend(struct peer *peer,`
			`struct per_peer_state *pps,`
			`struct channel *channel,`
			`const u8 *send_msg);`

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,`
			`u32 depth);`
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 */`