[bug]: `last_update` timestamp is in the future for a node

[bufo24]

Background

I came across a last updated date in 2030 in my mempool.space and was doubled checking the data via lncli and found out that my lnd has a channel with last_updated at "last_update": 1901350771 for node2.

Your environment

• lnd-0.16.0-beta
• Linux 5.10.103-v8+ aarch64 GNU/Linux
• bitcoin-24.0.1

Steps to reproduce

lnd lncli getchaninfo 770826920361984001

Expected behaviour

Return a last_update timestamp that is not in the future.

Actual behaviour

"last_update": 1901350771

[bitromortac]

I can confirm that the update has a timestamp that lies in the future. Did you recently change your fees or do you use other tools with your node?

[bufo24]

No, it's also not my channel

[guggero]

Can confirm that my node sees the same. But apparently also does 1ml.com: https://1ml.com/channel/770826920361984001/json

The spec isn't too specific on what valid values are. So it looks like this could've been set by the user of that node (by accident or for testing something). The timestamp is mostly used for ordering, according to https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#the-channel_update-message. So it could be that with this they made it impossible to ever update their channel, as all updates before that timestamp would be interpreted by every other node as "this update is before the most recent one I already have"...

[bitromortac]

Ah ok, we'll need to see what implication this has. Perhaps lnd would need to reject channel updates that lie too far in the future. I checked the graph and there are about 20 channels that have a timestamp far in the future. One can check that with lncli describegraph | jq '.edges |= map(select(.last_update >= 1700000000)) | .edges'.

[Roasbeef]

You can set it to pretty much any value. The only restriction is that the next timestamp be greater than the other one, so maybe someone is using custom values?