vincenzopalazzo
/
rgb-cln
1
0
Fork 0
Code Issues 1 Pull Requests Packages Projects Releases Wiki Activity
rgb-cln/lightningd/dual_open_control.h

23 lines
606 B
C
Raw Normal View History

dual-fund: accepter side implementation on lightningd wherein we add the dual_open_control functions
2020-09-09 11:10:28 +01: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 21:10:19 +00:00
#include <lightningd/subd.h>
dual-fund: accepter side implementation on lightningd wherein we add the dual_open_control functions
2020-09-09 11:10:28 +01: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 21:10:19 +00: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 01:05:06 +00: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 21:10:19 +00: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 19:03:06 +00: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 21:10:19 +00:00
u32 depth);
dual-fund: accepter side implementation on lightningd wherein we add the dual_open_control functions
2020-09-09 11:10:28 +01:00
#endif /* LIGHTNING_LIGHTNINGD_DUAL_OPEN_CONTROL_H */