mirrors/core-lightning
1
0
Fork 0
mirror of https://github.com/ElementsProject/lightning.git synced 2024-11-19 18:11:28 +01:00
Code Issues Projects Releases Wiki Activity
e677486fcc
core-lightning/lightningd/channel_control.h

45 lines
1.5 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 21:59:09 +01: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 12:08:01 +02:00
struct lightningd;
common/per_per_state: generalize lightningd/peer_comm Part 1 Encapsulating the peer state was a win for lightningd; not surprisingly, it's even more of a win for the other daemons, especially as we want to add a little gossip information. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2019-06-03 20:11:25 +02:00
struct per_peer_state;
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 05:56:32 +02: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 21:59:09 +01:00
lightningd: peer_start_channeld always returns true; make it void. It is always true, and we always ignore it. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-09 02:26:30 +02:00
void peer_start_channeld(struct channel *channel,
common/per_per_state: generalize lightningd/peer_comm Part 1 Encapsulating the peer state was a win for lightningd; not surprisingly, it's even more of a win for the other daemons, especially as we want to add a little gossip information. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2019-06-03 20:11:25 +02:00
struct per_peer_state *pps,
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 21:34:18 +02:00
const u8 *fwd_msg,
lightningd/channel_control: routines to control channeld (move from peer_control.c) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-20 21:59:09 +01:00
bool reconnected);
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 12:08:01 +02: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 17:57:19 +01: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 12:08:01 +02: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 07:08:11 +02: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 15:32:01 +02: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 12:08:01 +02:00
API: `fundchannel_cancel` can cancel fundchannel process before funding broadcast
2019-08-23 23:34:52 +02: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 06:34:26 +02:00
struct peer *peer);
API: `fundchannel_cancel` can cancel fundchannel process before funding broadcast
2019-08-23 23:34:52 +02: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 02:24:50 +01: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 02:25:54 +01:00
/* Record channel open (coin movement notifications) */
void channel_record_open(struct channel *channel);
channel control: break out separate method for canceling Break out a method for canceling a channel that will either loop through contacting the peer to tell them of the error or just directly cleans up if the peer is currently disconnected.
2019-12-12 01:23:19 +01:00
/* Forget a channel. Deletes the channel and handles all
* associated waiting commands, if present. Notifies peer if available */
void forget_channel(struct channel *channel, const char *err_msg);
channel_fallen_behind: break out functionality into two methods We'll need this for moving 'waiting for locked' into dualopend.
2020-12-10 21:02:02 +01:00
/* A channel has unrecoverably fallen behind */
void channel_fallen_behind(struct channel *channel, const u8 *msg);
lightningd/channel_control: routines to control channeld (move from peer_control.c) Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-02-20 21:59:09 +01:00
#endif /* LIGHTNING_LIGHTNINGD_CHANNEL_CONTROL_H */
Reference in New Issue Copy Permalink