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 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 19:40:28 +09:30			`#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 15:10:19 -06:00			`#include <lightningd/subd.h>`
dual-fund: accepter side implementation on lightningd wherein we add the dual_open_control functions 2020-09-09 19:40:28 +09:30
			`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 15:10:19 -06: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 19:40:28 +09:30			`#endif /* LIGHTNING_LIGHTNINGD_DUAL_OPEN_CONTROL_H */`