mirrors/core-lightning
1
0
Fork 0
mirror of https://github.com/ElementsProject/lightning.git synced 2025-02-23 23:06:44 +01:00
Code Issues Projects Releases Wiki Activity
core-lightning/lightningd/dual_open_control.h

32 lines
989 B
C
Raw Normal View History

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
patch lightningd-peer-fds.patch
2022-01-11 11:43:59 +10:30
struct peer_fd;
dual-fund: accepter side implementation on lightningd wherein we add the dual_open_control functions
2020-09-09 19:40:28 +09:30
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-23 06:57:29 +10:30
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 15:10:19 -06: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 21:42:18 +09:30
bool peer_restart_dualopend(struct peer *peer,
patch lightningd-peer-fds.patch
2022-01-11 11:43:59 +10:30
struct peer_fd *peer_fd,
dual-fund: keep track of aborted requests, seamlessly restart daemon Clean restart of daemon after a tx-abort is a nice way to work around the 'persistent' disconnect that we t-bast noticed. Changelog-Fixed: `dualopend`: Fix behavior for tx-aborts. No longer hangs, appropriately continues re-init of RBF requests without reconnction msg exchange.
2023-07-29 20:41:26 -05:00
struct channel *channel,
bool from_abort);
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-07 19:05:06 -06:00
lightningd: don't share funding_depth_cb for non-funding txs. We use the *same* callback for the funding tx, as well as for inflight dual-funding txs, as well as inflight splice txs. This is deeply confusing! Instead, use explicit cbs for splicing and df. Once they're locked in, use the normal callback. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2023-10-02 09:29:51 +10:30
void watch_opening_inflight(struct lightningd *ld,
struct channel_inflight *inflight);
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 11:58:00 -05: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 12:39:05 -06:00
common: BOLT update: option_anchors_zero_fee_htlc_tx is now simply "option_anchors". This is a difficult transition for us: this string appears in channel types. We make the transition now in the understanding that it will be more difficult in future. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Deprecated: JSON-RPC: `listpeers` `features` array string "option_anchors_zero_fee_htlc_tx": use "option_anchors" (spec renamed it). Changelog-Added: JSON-RPC: `listpeers` `features` array string uses "option_anchors" for feature 22/23, following renaming in BOLT 9. Changelog-Changed: JSON-RPC: `listclosedchannels`, `listpeerchannels`, `openchannel_update`, `openchannel_init`, `fundchannel`, `fundchannel_start` and `multifundchannel`: `channel_type` array `names` now contains "anchors" instead of "anchors_zero_fee_htlc_tx". Changelog-Changed: lightningd: `--list-features-only` now lists "option_anchors" instead of "option_anchors_zero_fee_htlc_tx".
2024-06-19 10:06:35 +09:30
void NO_NULL_ARGS json_add_unsaved_channel(struct command *cmd,
struct json_stream *response,
lightningd: remove `channels` from `listpeers`. Changelog-Removed: JSON-RPC: `listpeers` `channels` (deprecated v23.02, EOL v24.02) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2024-03-25 11:07:52 +10:30
const struct channel *channel,
const struct peer *peer);
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 16:50:42 -05: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 19:40:28 +09:30
#endif /* LIGHTNING_LIGHTNINGD_DUAL_OPEN_CONTROL_H */
Reference in a new issue Copy permalink