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

64 lines
2.2 KiB
C
Raw Normal View History

lightningd/channel_control: routines to control channeld (move from peer_control.c) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-21 07:29:09 +10:30
#ifndef LIGHTNING_LIGHTNINGD_CHANNEL_CONTROL_H
#define LIGHTNING_LIGHTNINGD_CHANNEL_CONTROL_H
#include "config.h"
#include <ccan/short_types/short_types.h>
#include <stdbool.h>
struct channel;
struct crypto_state;
channeld: don't do explicit state update. We missed it in some corner cases where we crashed/were killed between being told of the lockin and sending the channel_normal_operation message. When we were restarted, we were told both sides were locked in already, so we never updated the state. Pull the entire "tell channeld" logic into channel_control.c, and make it clear that we need to keep waching if we cant't tell channeld. I think we did get this correct in practice, since funding_announce_cb has the same test, but it's better to be clear. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-04-23 19:38:01 +09:30
struct lightningd;
patch lightningd-peer-fds.patch
2022-01-11 11:43:59 +10:30
struct peer_fd;
wallet: switch over to withdraw in module, remove lots of unused code. This removes the reservation cleanup at startup, too, now they're all using 'reserved_til'. This changes test_withdraw, since it asserted that outputs were marked spent as soon as we broadcast a transaction: now they're reserved until it's mined. Similarly, test_addfunds_from_block assumed we'd see funds as soon as we broadcast the tx. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Changed: JSON-RPC: `withdraw` now randomizes input and output order, not BIP69.
2020-08-28 13:26:32 +09:30
struct peer;
lightningd/channel_control: routines to control channeld (move from peer_control.c) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-21 07:29:09 +10:30
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_start_channeld(struct channel *channel,
patch lightningd-peer-fds.patch
2022-01-11 11:43:59 +10:30
struct peer_fd *peer_fd,
peer_channeld: pass over PSBT, remove second message We need the PSBT to create the finalized tx from once the peer's tx_signatures are received. Since we're passing the PSBT, we no longer need the secondary message to be passed, as it was derived from the PSBT. Also removes now unused witness serialization code
2020-09-10 14:34:18 -05:00
const u8 *fwd_msg,
channeld: add a message to read if we only want to reestablish. This supports reestablish on a closed channel: we tell channeld to respond to the reestablish message appropriately, then close the channel. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2021-06-15 14:37:10 +09:30
bool reconnected,
lightningd: handle reestablish directly from connectd. We don't need to hand it to channeld: it will read it! We simply need to tell it to expect it. Similarly, openingd/dualopend will never see it, so remove that logic. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-03-23 06:57:30 +10:30
bool reestablish_only);
lightningd/channel_control: routines to control channeld (move from peer_control.c) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-21 07:29:09 +10:30
lightningd: fold funding tx depth into a single function. Currently it's half done in funding_depth_cb, and half in channeld_tell_depth. It's very confusing as a result, with splicing, dual-funding and zeroconf. This does introduce a behaviour change: if a channel is NORMAL and it gets reorganized, we force close (unless we were the one who funded it, or it's zeroconf anyway). This is safer than continuing to use the channel in this case! Some tests are changed to zeroconf to make them work, but v2 doesn't support zeroconf, so that's removed. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2023-10-02 09:29:49 +10:30
/* Send message to channeld (if connected) to tell it about depth
* c.f. dualopen_tell_depth! */
void channeld_tell_depth(struct channel *channel,
const struct bitcoin_txid *txid,
u32 depth);
channel_control: Forget if unconfirmed for a long time and we are fundee. We should forget this as it is a potential DoS if we remember every funding txid that an attacker gave in a `funding_created` but never broadcasted.
2018-05-06 13:32:01 +00:00
/* Notify channels of new blocks. */
void channel_notify_new_block(struct lightningd *ld,
u32 block_height);
channeld: don't do explicit state update. We missed it in some corner cases where we crashed/were killed between being told of the lockin and sending the channel_normal_operation message. When we were restarted, we were told both sides were locked in already, so we never updated the state. Pull the entire "tell channeld" logic into channel_control.c, and make it clear that we need to keep waching if we cant't tell channeld. I think we did get this correct in practice, since funding_announce_cb has the same test, but it's better to be clear. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-04-23 19:38:01 +09:30
API: `fundchannel_cancel` can cancel fundchannel process before funding broadcast
2019-08-24 05:34:52 +08:00
/* Cancel the channel after `fundchannel_complete` succeeds
* but before funding broadcasts. */
struct command_result *cancel_channel_before_broadcast(struct command *cmd,
lightningd/opening_control.c: `fundchannel_cancel` no longer requires a `channel_id` argument. Fixes: #3785 Changelog-Changed: `fundchannel_cancel` no longer requires its undocumented `channel_id` argument after `fundchannel_complete`.
2020-06-24 12:34:26 +08:00
struct peer *peer);
API: `fundchannel_cancel` can cancel fundchannel process before funding broadcast
2019-08-24 05:34:52 +08:00
doc: update BOLTs to bc86304b4b0af5fd5ce9d24f74e2ebbceb7e2730 This contains the zeroconf stuff, with funding_locked renamed to channel_ready. I change that everywhere, and try to fix up the comments. Also the `alias` field is called `short_channel_id`. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Changed: Protocol: `funding_locked` is now called `channel_ready` as per latest BOLTs.
2022-09-10 11:40:31 +09:30
/* Update the channel info on channel_ready */
bool channel_on_channel_ready(struct channel *channel,
dualopend: tell lightningd what remote alias the peer sent. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2024-01-31 13:46:17 +10:30
const struct pubkey *next_per_commitment_point,
const struct short_channel_id *remote_alias);
channel_control: rename record_channel_open + expose
2020-11-23 19:25:54 -06:00
/* Record channel open (coin movement notifications) */
bkpr: for zerconfs, we still wanna know you're opening a channel We need a record of the channel account before you start sending payments through it. Normally we don't start allowing payments to be sent until after the channel has locked in but zeroconf does away with this assumption. Instead we push out a "channel_proposed" event, which should only show up for zeroconfs.
2022-07-19 14:35:56 -05:00
void channel_record_open(struct channel *channel, u32 blockheight, bool record_push);
channel_fallen_behind: break out functionality into two methods We'll need this for moving 'waiting for locked' into dualopend.
2020-12-10 14:02:02 -06:00
/* A channel has unrecoverably fallen behind */
common: No longer support new channels without option_static_remotekey. We still support *existing* channels. Just not new ones (before they could, in theory, explicitly ask for one). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2024-06-19 09:30:01 +09:30
void channel_fallen_behind(struct channel *channel);
channeld: keep local copy of latest channel_update for errors. Now we don't ask gossipd, but lightningd keeps channeld up-to-date. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2022-01-25 06:32:52 +10:30
lightningd: `setchannel` can set `ignorefeelimits`. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Added: JSON-RPC: `setchannel` adds a new `ignorefeelimits` parameter to allow peer to set arbitrary commitment transaction fees on a per-channel basis.
2023-07-21 16:49:22 +09:30
/* Tell channel about new feerates (owner must be channeld!) */
void channel_update_feerates(struct lightningd *ld, const struct channel *channel);
lightningd: fold funding tx depth into a single function. Currently it's half done in funding_depth_cb, and half in channeld_tell_depth. It's very confusing as a result, with splicing, dual-funding and zeroconf. This does introduce a behaviour change: if a channel is NORMAL and it gets reorganized, we force close (unless we were the one who funded it, or it's zeroconf anyway). This is safer than continuing to use the channel in this case! Some tests are changed to zeroconf to make them work, but v2 doesn't support zeroconf, so that's removed. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2023-10-02 09:29:49 +10:30
/* This channel is now locked in (the normal way, not zeroconf) */
void lockin_complete(struct channel *channel,
enum channel_state expected_state);
/* Accessor for zeroconf to tell us we've actually got an scid */
void lockin_has_completed(struct channel *channel, bool record_push);
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
/* Watch this incoming splice */
void watch_splice_inflight(struct lightningd *ld,
struct channel_inflight *inflight);
/* Update/set scid now this txid is mined. */
bool depthcb_update_scid(struct channel *channel,
lightningd: fix bug where we didn't correctly change outpoint of splice scid. We used the original channel funding output number. I'm not sure if this was true in the previous code, or a regression I introduced, but it caused occasonal failures in test_splice_gossip! Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2023-10-02 09:29:52 +10:30
const struct bitcoin_txid *txid,
const struct bitcoin_outpoint *outpoint);
lightningd/channel_control: routines to control channeld (move from peer_control.c) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-21 07:29:09 +10:30
#endif /* LIGHTNING_LIGHTNINGD_CHANNEL_CONTROL_H */
Reference in a new issue Copy permalink