Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting

[vjudeu@gazeta.pl]

> What happens if a series of blocks has a timestamp of 0xFFFFFFFF at the appropriate time?

The chain will halt for all old clients, because there is no 32-bit value greater than 0xffffffff.

> 1. Is not violated, since "not lower than" means "greater than or equal to"

No, because it has to be strictly "greater than" in the Bitcoin Core source code, it is rejected when it is "lower or equal to", see: https://github.com/bitcoin/bitcoin/blob/6f0cbc75be7644c276650fd98bfdb6358b827399/src/validation.cpp#L3089-L3094

> 2. Is not violated, since it would be a past actual real time.

If the current time is 0x0000000100000000, then the lowest 32 bits will point to some time around 1970, so for old clients two rules are violated at the same time.

> 3. Is not violated since 0xFFFFFFFF < 0x100000000.

This is hard to change, because 32-bit timestamps are included in block headers, so using any wider data type here will make it hardware-incompatible and will cause a hard-fork. That's why I think new timestamps should be placed in the coinbase transaction. But that still does not solve chain halting problem.

To test chain halting, all that is needed is starting regtest and producing one block with 0xffffffff timestamp, just after the Genesis Block. Then, median time is equal to 0xffffffff and adding any new blocks is no longer possible. The only soft-fork solution I can see require overwriting that block.

Example from https://bitcointalk.org/index.php?topic=5365359.0

submitblock 0100000006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0fffffffffffff7f200100000001020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0200f2052a010000001976a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac0000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000
null
generatetoaddress 1 mpXwg4jMtRhuSpVq4xS3HFHmCmWp9NyGKt
CreateNewBlock: TestBlockValidity failed: time-too-old, block's timestamp is too early (code -1)

I don't know any timestamp that can be used in any next block and accepted by old nodes.

On 2021-10-16 01:01:54 user ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> Good morning yanmaani,


> It's well-known. Nobody really cares, because it's so far off. Not
> possible to do by softfork, no.

I think it is possible by softfork if we try hard enough?


> 1.  The block timestamp may not be lower than the median of the last 11
>     blocks'
>
> 2.  The block timestamp may not be greater than the current time plus two
>     hours
>
> 3.  The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106
>     06:28:16 +0000)

What happens if a series of blocks has a timestamp of 0xFFFFFFFF at the appropriate time?

In that case:

1.  Is not violated, since "not lower than" means "greater than or equal to", and after a while the median becomes 0xFFFFFFFF and 0xFFFFFFFF == 0xFFFFFFFF
2.  Is not violated, since it would be a past actual real time.
3.  Is not violated since 0xFFFFFFFF < 0x100000000.

In that case, we could then add an additional rule, which is that a 64-bit (or 128-bit, or 256-bit) timestamp has to be present in the coinbase transaction, with similar rules except translated to 64-bit/128-bit/256-bit.

Possibly a similar scheme could be used for `nLockTime`; we could put a 64-bit `nLockTime64` in that additional signed block in Taproot SegWit v1 if the legacy v`nLockTime` is at the maximum seconds-timelock possible.

Regards,
ZmnSCPxj