2-week timestamp expiry on `channel_update` implies timestamp is epoch time

[rustyrussell]

Section 7 says "nodes MAY prune channels should the timestamp of the latest channel_update be older than 2 weeks (1209600 seconds)"

Yet timestamps are only required to be sequential, not an actual timestamp ("The creating node MUST set timestamp to be greater than that for any previous node_announcement it has created. It MAY base it on a UNIX timestamp.", so there's no way to know the age of a timestamp, at least not by looking at the timestamp.

Reported-by: @shannona

[pm47]

What are the downsides of requiring timestamps to be based on epoch time?

[rustyrussell]

Pierre-Marie Padiou <notifications@github.com> writes:

What are the downsides of requiring timestamps to be based on epoch time?

We don't have a good way of enforcing it. If I put a timestamp of 2020 in the announcement, will it never time out? Do you reject it as stupid? It would be fairly simple to say "can't be greater than getmediantime()" of past 11 blocks; a conservative implementation would use the previous block, to avoid the update getting refused by peers which don't know the lastest block. That's approximately an hour in the past. Heck, we could add 3600 seconds to make it look like 'current time'. Then the requirements are well-defined.