4

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. It shows channel policies for both peers. Why do the results I get show null for both peers?

3 Answers 3

1

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 or the gossip chapter of mastering the Lightning Network.

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?

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 Rene.

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.