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

27 lines
768 B
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;
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
bool peer_start_channeld(struct channel *channel,
const struct crypto_state *cs,
int peer_fd, int gossip_fd,
const u8 *funding_signed,
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 11:08:01 +01:00
/* Returns true if subd told, otherwise false. */
bool channel_tell_funding_locked(struct lightningd *ld,
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
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 */