core-lightning/lightningd/channel_state.h
Rusty Russell 36b1cac6e6 lightningd: new state AWAITING_UNILATERAL.
When in this state, we send a canned error "Awaiting unilateral close".
We enter this both when we drop to chain, and when we're trying to get
them to drop to chain due to option_data_loss_protect.

As this state (unlike channel errors) is saved to the database, it means
we will *never* talk to a peer again in this state, so they can't
confuse us.

Since we set this state in channel_fail_permanent() (which is the only
place we call drop_to_chain for a unilateral close), we don't need to
save to the db: channel_set_state() does that for us.

This state change has a subtle effect: we return WIRE_UNKNOWN_NEXT_PEER
instead of WIRE_TEMPORARY_CHANNEL_FAILURE as soon as we get a failure
with a peer.  To provoke a temporary failure in test_pay_disconnect we
take the node offline.

Reported-by: Christian Decker @cdecker
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-23 14:46:22 +02:00

34 lines
792 B
C

#ifndef LIGHTNING_LIGHTNINGD_CHANNEL_STATE_H
#define LIGHTNING_LIGHTNINGD_CHANNEL_STATE_H
#include "config.h"
/* These are in the database, so don't renumber them! */
enum channel_state {
/* In channeld, still waiting for lockin. */
CHANNELD_AWAITING_LOCKIN = 2,
/* Normal operating state. */
CHANNELD_NORMAL,
/* We are closing, pending HTLC resolution. */
CHANNELD_SHUTTING_DOWN,
/* Exchanging signatures on closing tx. */
CLOSINGD_SIGEXCHANGE,
/* Waiting for onchain event. */
CLOSINGD_COMPLETE,
/* Waiting for unilateral close to hit blockchain. */
AWAITING_UNILATERAL,
/* We've seen the funding spent, we're waiting for onchaind. */
FUNDING_SPEND_SEEN,
/* On chain */
ONCHAIN
};
#define CHANNEL_STATE_MAX ONCHAIN
#endif /* LIGHTNING_LIGHTNINGD_CHANNEL_STATE_H */