Post
Topic
Board Development & Technical Discussion
Merits 1 from 1 user
Re: Going backward in time
by
BlackHatCoiner
on 12/10/2021, 20:01:05 UTC
⭐ Merited by vapourminer (1)
Imagine that some transaction have NLockTime set in October 2021. Does it mean that if such transaction is included in the chain, then it is impossible to create any next block with any timestamp below that NLockTime? How it is checked?
You sound like myself, couple of months ago when I had a similar query. Read Re: Strange Timestamp Argument.

If you have a new block header, is it compared with some globally stored max(NLockTimeTx1,NLockTimeTx2,...,NLockTimeTxN)?
Are you asking if it's possible to include a transaction whose timestamp is greater than the block's? Whether it does or does not (I honestly don't know, it is required to check the source code), but what does this have to do with your questioning?

The difficulty isn't affected from the transactions' timestamp, but from the blocks'.

For example: an adversary miner could start producing blocks with future timestamps to drop difficulty, then jump back in time (if it is possible and if that does not require dealing with endlessly growing difficulty)
That's true if he's the only miner. As long as there're other miners and an honest majority, willing to play by the rules, what you describe cannot happen due to the median time limitation that is calculated from the comparison of the last 11 blocks. It's written in the nLockTime wiki page.

In other words, one cannot manipulate the timestamp without having the majority of the computational power. The other miners will sooner or later get ahead him.