<p>I cannot know for sure the reason for this behavior but given the inner workings of the Gossip Protocol there is a high likelihood that the following is the reason.</p>
<p>Channels are anounced via the <code>channel_announcement</code> message. These messages contain more or less the information that you saw in your output. The capacity is not part of the message but retrieved by looking at the bitcoin node for the <code>chan_point</code> which is the funding transaction id and the output of the funding tx of the channel.</p>
<p>Nodes then independently send out <code>channel_updates</code> that contain their own routing policies. So what can happen is that your lightning node is new and has already received the <code>channel announcement</code> but no <code>channel_update</code> yet. Another possibility is that 1ML shows some old values of a <code>channel update</code> which your newis node may not see. This could happen if the the peers of the channel have been offline for some time or not sending out <code>channel_updates</code> for some time as nodes on the lightning network will only gossip <code>channel_updates</code> that are younger than two weeks. So in case there was no channel update within the last 14 days you will only get to see the announcement. There could be many other reasons if you want to digg deeper I suggest to read either <a href="https://github.com/lightning/bolts/blob/master/07-routing-gossip.md" rel="nofollow noreferrer">BOLT 07 of the spec</a> or the <a href="https://github.com/lnbook/lnbook/blob/develop/11_gossip_channel_graph.asciidoc" rel="nofollow noreferrer">gossip chapter of mastering the Lightning Network</a>.</p>

CC BY-SA 4.0
2023-01-25T16:18:16.207Z
2023-01-25T16:18:16.207Z
Rene Pickhardt
<p>Many channels with last_update =0 and node policy missing are closed channels. for most of them, it shows capacity as 0. Here is a breakdown of channels pulled on 04/02/2024.</p>
<div class="s-table-container"><table class="s-table">
<thead>
<tr>
<th>Group</th>
<th>Group</th>
<th>Count</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>last update &gt; 0, capacity &gt; 0, Both policies are good - non-null</td>
<td>37067</td>
</tr>
<tr>
<td>2</td>
<td>last update = 0, capacity = 0, Both are null</td>
<td>13915</td>
</tr>
<tr>
<td>3</td>
<td>last update = 0, capacity &gt; 0, Both are null</td>
<td>780</td>
</tr>
<tr>
<td>4</td>
<td>last update &gt; 0, capacity &gt; 0, One policy is null</td>
<td>68</td>
</tr>
<tr>
<td>5</td>
<td>last update &gt; 0, capacity = 0, Both policies are good - non-null</td>
<td>28</td>
</tr>
<tr>
<td>6</td>
<td>last update &gt; 0, capacity = 0, One policy is null</td>
<td>3</td>
</tr>
</tbody>
</table></div>
<p>To understand how the data is getting captured, it would make sense to look at each group above, and based on channel_id figure out what's up with the channel. I have looked at more than 10 channel_id randomly from group 2 some time back, and mempool.space records those as closed.</p>
<p>The use case you have, non-zero capacity, last update, and node policy missing is a small fraction. 780 out of 50K. I would assume, it has to do more with channel update propagation as pointed out by Rene.</p>
<p>However, I'll update the thread as I learn more about the 'describegraph'.</p>

CC BY-SA 4.0
2024-04-02T22:56:05.700Z
2024-04-02T22:56:05.700Z
Saurabh Kumar
<p>From my experience the <code>lncli describegraph</code> doesn't render reliable data. I find lot's of dead edges and wrong &quot;<code>last_update</code>&quot; timestamps. Maybe cause my node is &gt; 2years old. Fortunately, the lnd still seems to work correct. I.e. the <code>listchannels</code> works correct while the <code>describegraph</code> is full of dead nodes and dead channels with wrong timestamps.
Maybe routing problems are also related to this. Btw. is your output.json also about 73 MB?</p>

CC BY-SA 4.0
2024-02-26T15:39:26.717Z
2024-02-26T15:39:26.717Z
Rainer Feike
<p>The <code>describegraph</code> command for <code>lncli</code> returns several channels that have at least one policy set to null. In many cases, they are both set to null, and <code>last_update</code> is set to 0, as shown in the following example.</p>
<pre><code>{
    &quot;channel_id&quot;: &quot;754441998110162945&quot;,
    &quot;chan_point&quot;: &quot;cb9eb6ae3f285da7cd120a83db7ceca4fee2c19eb72513530646e1bd340e1663:1&quot;,
    &quot;last_update&quot;: 0,
    &quot;node1_pub&quot;: &quot;0227e8baab7b4397a88ea2bb3976a7fc8f975aa4fc28ef9272a33b6a1291ffff63&quot;,
    &quot;node2_pub&quot;: &quot;03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f&quot;,
    &quot;capacity&quot;: &quot;480000&quot;,
    &quot;node1_policy&quot;: null,
    &quot;node2_policy&quot;: null
}
</code></pre>
<p>How is null supposed to be interpreted?</p>
<p>The channel above has a <a href="https://1ml.com/channel/754441998110162945" rel="nofollow noreferrer">page on 1ML</a>. It shows channel policies for both peers. Why do the results I get show null for both peers?</p>

<lightning-network><lightning-network-daemon><lncli>
LND describegraph returns channels with null policies
Zephyrus
# LND describegraph returns channels with null policies

(Asked by: username_0 on 2023-01-25)

The `describegraph` command for `lncli` returns several channels that have at least one policy set to null. In many cases, they are both set to null, and `last_update` is set to 0, as shown in the following example.

```
{
    "channel_id": "754441998110162945",
    "chan_point": "cb9eb6ae3f285da7cd120a83db7ceca4fee2c19eb72513530646e1bd340e1663:1",
    "last_update": 0,
    "node1_pub": "0227e8baab7b4397a88ea2bb3976a7fc8f975aa4fc28ef9272a33b6a1291ffff63",
    "node2_pub": "03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f",
    "capacity": "480000",
    "node1_policy": null,
    "node2_policy": null
}

```

How is null supposed to be interpreted?

The channel above has a [page on 1ML](https://1ml.com/channel/754441998110162945). It shows channel policies for both peers. Why do the results I get show null for both peers?

**Tags:** lightning-network, lightning-network-daemon, lncli


---

## 3 answers

### Answer by username_1 on 2023-01-25. Score: 1 | Accepted answer

I cannot know for sure the reason for this behavior but given the inner workings of the Gossip Protocol there is a high likelihood that the following is the reason.

Channels are anounced via the `channel_announcement` message. These messages contain more or less the information that you saw in your output. The capacity is not part of the message but retrieved by looking at the bitcoin node for the `chan_point` which is the funding transaction id and the output of the funding tx of the channel.

Nodes then independently send out `channel_updates` that contain their own routing policies. So what can happen is that your lightning node is new and has already received the `channel announcement` but no `channel_update` yet. Another possibility is that 1ML shows some old values of a `channel update` which your newis node may not see. This could happen if the the peers of the channel have been offline for some time or not sending out `channel_updates` for some time as nodes on the lightning network will only gossip `channel_updates` that are younger than two weeks. So in case there was no channel update within the last 14 days you will only get to see the announcement. There could be many other reasons if you want to digg deeper I suggest to read either [BOLT 07 of the spec](https://github.com/lightning/bolts/blob/master/07-routing-gossip.md) or the [gossip chapter of mastering the Lightning Network](https://github.com/lnbook/lnbook/blob/develop/11_gossip_channel_graph.asciidoc).


---

### Answer by username_2 on 2024-04-02. Score: 0

Many channels with last\_update =0 and node policy missing are closed channels. for most of them, it shows capacity as 0. Here is a breakdown of channels pulled on 04/02/2024.

| Group | Group | Count |
| --- | --- | --- |
| 1 | last update > 0, capacity > 0, Both policies are good - non-null | 37067 |
| 2 | last update = 0, capacity = 0, Both are null | 13915 |
| 3 | last update = 0, capacity > 0, Both are null | 780 |
| 4 | last update > 0, capacity > 0, One policy is null | 68 |
| 5 | last update > 0, capacity = 0, Both policies are good - non-null | 28 |
| 6 | last update > 0, capacity = 0, One policy is null | 3 |

To understand how the data is getting captured, it would make sense to look at each group above, and based on channel\_id figure out what's up with the channel. I have looked at more than 10 channel\_id randomly from group 2 some time back, and mempool.space records those as closed.

The use case you have, non-zero capacity, last update, and node policy missing is a small fraction. 780 out of 50K. I would assume, it has to do more with channel update propagation as pointed out by username_1.

However, I'll update the thread as I learn more about the 'describegraph'.


---

### Answer by username_3 on 2024-02-26. Score: 0

From my experience the `lncli describegraph` doesn't render reliable data. I find lot's of dead edges and wrong "`last_update`" timestamps. Maybe cause my node is > 2years old. Fortunately, the lnd still seems to work correct. I.e. the `listchannels` works correct while the `describegraph` is full of dead nodes and dead channels with wrong timestamps.
Maybe routing problems are also related to this. Btw. is your output.json also about 73 MB?


---

