On the Lightning Network, after how much time since the last received channel update is a channel considered inactive?
1 Answer
If you look at the channel_update message
of BOLT 07 you will find that a node
- MAY create and send a
channel_update
with thedisable
bit set to 1, to signal a channel's temporary unavailability (e.g. due to a loss of connectivity) OR permanent unavailability (e.g. prior to an on-chain settlement).
- MAY sent a subsequent
channel_update
with thedisable
bit set to 0 to re-enable the channel.
This means that if you shutdown your node correctly the node or the peer will set the channel to inactive and send a channel message. In particular there is no time(out) encoded to the protocol.
If your node stays online and the TCP-connection stays alive the channel won't become inactive.
If your node dies the peer might send an inactive message. However from the specification it is not clear when and how this will happen.
In general it is considered to be a good practice to shut down your node properly and send out the fact that the channel is inactive so that others won't experience unnecessary routing errors. I think lnd
will start collecting statistics about failed routing attempts and locally start to rank nodes by their reliability. While planned downtime is also not as nice as constant uptime it will certainly not downrank your node as much as discovered downtime during routing attempts.
Sorry that this answer might be not as satisfying as you hoped for. Another way to approach this would be to look at the implementations and check when and how they send channel_update
messages. For example in c-lightning the send_channel_update function
is called 5 times. in Most cases to activate a channel. I can only find 2 cases in which the channel might be broadcasted to be inactive:
static void maybe_send_shutdown(struct peer *peer)
{
u8 *msg;
if (!peer->send_shutdown)
return;
/* Send a disable channel_update so others don't try to route
* over us */
send_channel_update(peer, ROUTING_FLAGS_DISABLED);
msg = towire_shutdown(NULL, &peer->channel_id, peer->final_scriptpubkey);
sync_crypto_write(peer->pps, take(msg));
peer->send_shutdown = false;
peer->shutdown_sent[LOCAL] = true;
billboard_update(peer);
}
and:
static void handle_peer_shutdown(struct peer *peer, const u8 *shutdown)
{
struct channel_id channel_id;
u8 *scriptpubkey;
/* Disable the channel. */
send_channel_update(peer, ROUTING_FLAGS_DISABLED);
if (!fromwire_shutdown(tmpctx, shutdown, &channel_id, &scriptpubkey))
peer_failed(peer->pps,
&peer->channel_id,
"Bad shutdown %s", tal_hex(peer, shutdown));
...
The last one handle_peer_shutdown
is the regular shutdown the first one maybe_send_shutdown
seems to be called at three points in the code. It can be traced down from there to see if there are any special circumstances at which the channel is broadcasted as inactive.
-
So the inactivity of a channel is generally something that is announced from the remote node, not something that your own node assumes, right? Commented Sep 4, 2019 at 7:35
-
The common case is that you would deactivate your channel / node before shutting down by sending that message. If your peer detects it the peer can also send out the channel_update for the remote note / the channel Commented Sep 4, 2019 at 11:33
-
1
The timestamp field is used by nodes for pruning channel_updates that are either too far in the future or have not been updated in two weeks;
(BOLT #7)– Mark HCommented Sep 4, 2019 at 17:46