<p>If you look at the <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_update-message" rel="noreferrer"><code>channel_update message</code> of BOLT 07</a> you will find that a node</p>

<blockquote>
  <ul>
  <li>MAY create and send a <code>channel_update</code> with the <code>disable</code> 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).
  
  <ul>
  <li>MAY sent a subsequent <code>channel_update</code> with the <code>disable</code> bit  set to 0 to
  re-enable the channel.</li>
  </ul></li>
  </ul>
</blockquote>

<p>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.</p>

<p>If your node stays online and the TCP-connection stays alive the channel won't become inactive. </p>

<p>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. </p>

<p>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 <code>lnd</code> 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.</p>

<p>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 <code>channel_update</code> messages. For example <a href="https://github.com/ElementsProject/lightning/blob/5e3e2f4e1758f9d2735b1f32db382318a2a323f7/channeld/channeld.c" rel="noreferrer">in c-lightning the <code>send_channel_update function</code> is called 5 times</a>. in Most cases to activate a channel. I can only find 2 cases in which the channel might be broadcasted to be inactive: </p>

<pre><code>static void maybe_send_shutdown(struct peer *peer)
{
    u8 *msg;

    if (!peer-&gt;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, &amp;peer-&gt;channel_id, peer-&gt;final_scriptpubkey);
    sync_crypto_write(peer-&gt;pps, take(msg));
    peer-&gt;send_shutdown = false;
    peer-&gt;shutdown_sent[LOCAL] = true;
    billboard_update(peer);
}
</code></pre>

<p>and: </p>

<pre><code>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, &amp;channel_id, &amp;scriptpubkey))
        peer_failed(peer-&gt;pps,
                &amp;peer-&gt;channel_id,
                "Bad shutdown %s", tal_hex(peer, shutdown));
    ...
</code></pre>

<p>The last one <code>handle_peer_shutdown</code> is the regular shutdown the first one <code>maybe_send_shutdown</code> 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. </p>

CC BY-SA 4.0
2019-09-04T07:35:11.133Z
So the inactivity of a channel is generally something that is announced from the remote node, not something that your own node assumes, right?
Dalit Sairio
CC BY-SA 4.0
2019-09-04T11:33:36.123Z
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
Rene Pickhardt
CC BY-SA 4.0
2019-09-04T17:46:53.657Z
`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 H
CC BY-SA 4.0
2019-09-03T18:48:14.720Z
2019-09-03T18:53:41.900Z
2019-09-03T18:53:41.900Z
Rene Pickhardt
<p>On the Lightning Network, after how much time since the last received channel update is a channel considered inactive?</p>

<lightning-network><ln-node-reliability>
What is the definition of an inactive channel?
Dalit Sairio
# What is the definition of an inactive channel?

(Asked by: username_0 on 2019-09-03)

On the Lightning Network, after how much time since the last received channel update is a channel considered inactive?

**Tags:** lightning-network, ln-node-reliability


---

## 1 answers

### Answer by username_1 on 2019-09-03. Score: 5 | Accepted answer

If you look at the [`channel_update message` of BOLT 07](https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md#the-channel_update-message) you will find that a node

> * MAY create and send a `channel_update` with the `disable` 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 the `disable` 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](https://github.com/ElementsProject/lightning/blob/5e3e2f4e1758f9d2735b1f32db382318a2a323f7/channeld/channeld.c). 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.

> **Comments:**
> **username_0**: So the inactivity of a channel is generally something that is announced from the remote node, not something that your own node assumes, right?  
> **username_1**: 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  
> **username_2**: `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)  

---

