Topic: Going backward in time (Read 236 times)

Yes, it was the newest official release 22.0 for Windows.

This is true if we talk about reaching 0x80000000 and higher values. However, if I understand that correctly, the whole chain will halt after reaching median time 0xffffffff, so producing any new blocks after year 2106 will be impossible, because of currently used consensus rules.

I can reproduce the same error messages in 22.0, so I guess all recent versions are affected, maybe some older version handled that differently, but I think many clients will crash in 2038, including custom software used by miners. Also, I cannot produce any valid block after reaching 0xffffffff median time, I tried many different 32-bit values, but each time Bitcoin Core thinks that the time is too old.

2038y problem was reported in March 4th, on this issue:

https://github.com/bitcoin/bitcoin/issues/21356


It seems we'll be fine if we use an updated version of std::chrono.

It seems that Bitcoin Core is affected by 2038 year problem, I set my clock to 0x7fffffff and the client is halted with this assertion, because when reaching 0x80000000 it is treated as a negative value.

Edit: It seems that I was right and when median time will reach 0xffffffff, it will be impossible to create any new blocks in such chain. Then, modifying the chain is no longer possible without chain reorganization, because the timestamp of the next block has to be greater than 0xffffffff, so there is no 32-bit value that can meet this rule.

In block header the value can be either signed or unsigned since it is just a byte stream (bitcoin core uses unsigned Int32) but when it comes to comparison it will be cast to (signed) Int64 then compared to address the overflows.

Standard unix time uses a signed 4-byte integer. If I remember correctly, Bitcoin blocks use an unsigned 4-byte integer. This allows an additional 68 years before it becomes a problem.

It seems I did not remember correctly. See the next 2 comments below.

I'm not sure if the overflow has been addressed in code yet, but if it hasn't, then we've got about 85 more years to take care of it.

It appears it has not been.  See below.

I tested some values by starting from zero unix time and saw that it always can only go forward, because it always has to be greater than the median time of the last 11 blocks. But I have another time-related question: will the chain be halted when reaching median time equal to 0xffffffff? Or maybe we have some kind of overflow bug here, as it was in Value Overflow Incident, but time-related, so is it possible to jump back from 0xffffffff to 0x00000000?

The answer to your question is no, in multiple ways.

First of all, you couldn't create a valid block that precedes the origin block in position in the chain (or even one that closely follows the origin block) without re-performing proof-of-work on EVERY BLOCK that has been created since.  This is because each block contains the hash of its immediately preceding block.  To create a block that precedes any given block, you'd have to create a block that hashes to the EXACT value that is already stored in the block that you are trying to immediately precede.  Since this is effectively impossible, the only alternative is to re-perform the proof-of-work on the block that immediately follows yours using the hash of your block as the "previous block" for your re-hashing attempt.  Unfortunately, this will change the value of that block, so you'll need to re-perform proof-of-work on the block that follows it, and so on.  That's WHY it's called a "blockCHAIN".

Alternately, if you wanted to create a block that just gets placed at the most recent end of the chain as a new "most recently created block", you'll be bound by the rule that any valid block cannot have a timestamp earlier than the median of the timestamps in the 11 blocks that immediately precede it. As such, you can't create a block that is added to the tip of the chain with a date older than a few hours ago.

You sound like myself, couple of months ago when I had a similar query. Read Re: Strange Timestamp Argument.

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'.

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, it's impossible. 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.

Because if doing so is possible, then another kind of attack is possible. 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), and then create a deep reorganization, because a lot of blocks with smaller difficulty could create a sum of chainwork greater than the honest chain. That attack could be of course noticed by anyone, but if it matches consensus rules, then it will be accepted by existing clients. Also, there are some altcoins with different difficulty adjustment algorithms, if the same way of checking time is repeated in other coins, then that altcoins could be potentially easier attacked in this way, because their difficulty can be changed sooner than for example every two weeks.

Edit:
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? If you have a new block header, is it compared with some globally stored max(NLockTimeTx1,NLockTimeTx2,...,NLockTimeTxN)?

If you started from the very first block, then I don't know, I'll have to look into the code, but: Why does it matter? If a new person wanted to start another chain, they'd mine themselves the first block(s).

If you didn't start from the first block, then no. Because of NLockTime.

Is it possible to go back in time in a chain? For example, starting from 2009 is it possible to produce blocks with earlier and earlier timestamps and for example reach 2005? Or is there any strict requirement that block timestamps have to go forward? Because if there are three sources of time: local time, time from other nodes and time from block headers, if the first two will be faked, is it possible to also fake block timestamps and set any date, if the whole chain will be long enough?