[bug]: describegraph; node's last_update should include node's edges' last_update

[bartoli]

Background

The channel advisor at lnshortcut.ovh uses lncli describegraph to get a vew of the network. It has a basic filtering of nodes/channels that are meaningless to make network analysis faster

One of those filters is to consider that nodes that have not been updated in 60 days are considered inactive. It was based on last_update field of a node in describegraph json output. But this alone filters out 2/3 of all known public nodes! By just changing my code to consider that a nodes last update is the biggest date of the last_update of the node, and the last_update of each of it's channels, the filtering is now giving a lot more reasonable filtering.

Your environment

lnd 0.18 on linux x86-64

Expected behaviour

I think lnd should include the update time of the edges to the update time of the node. If not the edges'update time, at least the update time of the edge policy on his side?

Actual behaviour

The nodes last_update value is often lower than the last_update of some of it's channels

[spotted-cat]

@saubyk Can you assign me the issue, are there any other resources I should be looking into? or suggestions?

[saubyk]

@saubyk Can you assign me the issue, are there any other resources I should be looking into? or suggestions?

Hi @spotted-cat do you have any familiarity with Lightning network? I was not able to spot any relevant contributions on your GitHub profile hence asking. This issue even though "good for beginners" would still require some basic understanding of Lightning Network as well as LND code base.

If this is first time you're looking into this project, it may not be the best 'first problem to address' for you.

[spotted-cat]

@saubyk Can you assign me the issue, are there any other resources I should be looking into? or suggestions?

Hi @spotted-cat do you have any familiarity with Lightning network? I was not able to spot any relevant contributions on your GitHub profile hence asking. This issue even though "good for beginners" would still require some basic understanding of Lightning Network as well as LND code base.

If this is first time you're looking into this project, it may not be the best 'first problem to address' for you.

Thankyou for replying @saubyk , yes I am new to Lightning Network, though I have started to look into the resources and docs made for new contributors here and looking into understanding the Lightning Network codebase. Also the problem at hand do is not the most primitive, but I don't mind tackling the challenges as that is the part of the learning process.

I will outline my strategy here as soon as I am confident with Lightning Network, which you can check on and guide me if needed.

is this okay here?

[spotted-cat]

@saubyk sorry for the delay, I was not well. So well looking into the code and all the documentations,

So there are several approaches for the problem mentioned in the issue,

1) The straight forward way mentioned itself in the issue, compare the node with it's channel edges and take the latest last_update

But this method seems problematic as the last_update field for ChannelEdge struct is marked as deprecated inside the code, so I don't think using it is wise choice.

2) The other way is ofcourse to use Edge Policy's last_update But do we should directly change the last_update field of the LightningNode or more better provide another field for this 'smarter' last_update field in the response of DescribeGraph?

[saubyk]

2. The other way is ofcourse to use Edge Policy's last_update

Edge policy last_update is not a wise choice as the channel state can change more frequently (and is more important to track) than the policy

[saubyk]

based on the chats I had with @alexbosworth I think we would close this issue.

This requirement is best handled by reporting logic, rather than LND updating the timestamp of node's last_update with the channel's

Important to note that within the messaging interchange between the nodes on lightning network, information is exchanged both at the node level (when node level parameters are updated) and the channel level (when channel state is updated) and it's important to keep them separate

[saubyk]

@spotted-cat you can look for other beginner issues, if you are keen to contribute to LND. thanks for your interest.

[spotted-cat]

@spotted-cat you can look for other beginner issues, if you are keen to contribute to LND. thanks for your interest.

Thankyou for your inputs and insights. Will look into some other issue here on LND :)