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

47 lines
1.4 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-20 20:59:09 +00:00
#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 11:08:01 +01:00
struct lightningd;
patch lightningd-peer-fds.patch
2022-01-11 01:13:59 +00:00
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 04:56:32 +01:00
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-20 20:59:09 +00: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 13:12:18 +01:00
bool peer_start_channeld(struct channel *channel,
patch lightningd-peer-fds.patch
2022-01-11 01:13:59 +00:00
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 20:34:18 +01: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 06:07:10 +01:00
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-22 20:27:30 +00:00
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-20 20:59:09 +00:00
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 11:08:01 +01:00
/* Returns true if subd told, otherwise false. */
fix:Add infor about how many blocks needed until funding is confirmed 1. Rename channel_funding_locked to channel_funding_depth in channeld/channel_wire.csv. 2. Add minimum_depth in struct channel in common/initial_channel.h and change corresponding init function: new_initial_channel(). 3. Add confirmation_needed in struct peer in channeld/channeld.c. 4. Rename channel_tell_funding_locked to channel_tell_depth. 5. Call channel_tell_depth even if depth < minimum, and still call lockin_complete in channel_tell_depth, iff depth > minimum_depth. 6. channeld ignore the channel_funding_depth unless its > minimum_depth(except to update billboard, and set peer->confirmation_needed = minimum_depth - depth).
2019-02-26 16:57:19 +00:00
bool channel_tell_depth(struct lightningd *ld,
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 11:08:01 +01:00
struct channel *channel,
channeld: simplify announce/locked-in callback, Just have a "new depth" callback, and let channeld do the right thing. This makes the channeld paths a bit more straightforward. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-05-17 06:08:11 +01:00
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 14:32:01 +01: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 11:08:01 +01:00
API: `fundchannel_cancel` can cancel fundchannel process before funding broadcast
2019-08-23 22:34:52 +01: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 05:34:26 +01:00
struct peer *peer);
API: `fundchannel_cancel` can cancel fundchannel process before funding broadcast
2019-08-23 22:34:52 +01:00
channel_control: break out function for on_funding_locked We're about to move channel-locking over to dualopend, and will want to reuse this.
2020-11-24 01:24:50 +00:00
/* Update the channel info on funding locked */
bool channel_on_funding_locked(struct channel *channel,
struct pubkey *next_per_commitment_point);
channel_control: rename record_channel_open + expose
2020-11-24 01:25:54 +00:00
/* Record channel open (coin movement notifications) */
void channel_record_open(struct channel *channel);
channel_fallen_behind: break out functionality into two methods We'll need this for moving 'waiting for locked' into dualopend.
2020-12-10 20:02:02 +00:00
/* A channel has unrecoverably fallen behind */
void channel_fallen_behind(struct channel *channel, const u8 *msg);
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-24 20:02:52 +00:00
/* Fresh channel_update for this channel. */
void channel_replace_update(struct channel *channel, u8 *update TAKES);
lightningd/channel_control: routines to control channeld (move from peer_control.c) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-20 20:59:09 +00:00
#endif /* LIGHTNING_LIGHTNINGD_CHANNEL_CONTROL_H */