Node sync checks for mining purposes

Mining
1

In Bitcoin, and as a consequence in our node implementation as well, getBlockTemplate RPC request doesn’t serve block templates for mining if it thinks the node is not synced, and therefore mining will be pointless. And the indication if the node is synced or not is to check if the difference between the tip and the local time is greater than 24 hours (12 hours in our case).
We had a problem with this behaviour when we’ve run a development network that stopped mining for about a day because of a bug, and after the bug was fixed the mining hasn’t recovered because none of the nodes served block templates, because they thought they are not synced.
The simplest solution that comes in mind to fix it is to check if any of your peers reported in his version message that he has a selected tip that you don’t know, but the problem with that is that it’s very cheap to produce version messages with non existing hashes, and deceive the whole network to think that it’s not synced and shouldn’t mine.
So after a discussion with @hashdag we came to a solution: in order to check if someone really has tips that you don’t know, you have to check when was the last time he sent you a valid non-orphan block. If he keeps sending you blocks, it’s a proof by deeds that he has more up-to-date state than you.

So in the bottom line, a node will serve block templates unless its selected tip is older than X seconds and it got at least one non-orphan valid block in the last Y minutes.

P.S
It’s not related to the discussion, but a node with no peers shouldn’t serve block templates as well.

2

As discussed elsewhere, this method isn’t secure enough, b/c a miner with a small hashrate can feed us its blocks in its full rate and deceive us thus to stop mining (if we are behind on timestamp). Observe that the regular sync rate should normally equal the block creation rate \lambda (in Kaspa \lambda=1 block per sec). So a miner should stop mining if its timestamp is behind (as you defined in the post) and its sync rate is above \lambda, over some long-but-not-too-long interval.

Also, note that using the timestamp as you suggested assumes that the difficulty adjustment mechanism functioned properly throughout the entire history till now.