Your solution seems to solve the problem of chain halting, but there are more issues. For example: if you have some time modulo 2^32, then you no longer know if timestamp zero is related to 1970 or 2106 or some higher year. Your "k" value representing in fact the most significant 32 bits of 64-bit timestamp has to be stored in all cases where time is used. If there is no "k", then zero should be used for backward compatibility. Skipping "k" could cause problems related to OP_CHECKLOCKTIMEVERIFY or nLockTime, because if some transaction was timestamped to 0xbadc0ded, then that transaction will be valid in 0x00000000badc0ded, invalid in 0x0000000100000000, and valid again in 0x00000001badc0ded, the same for timelocked outputs.
So, I think your "k" value should be added to the coinbase transaction, then you can combine two 32-bit values, the lower bits from the block header and the higher bits from the coinbase transaction. Also, adding your "k" value transaction nLockTime field is needed (maybe in a similar way as transaction witness was added in Segwit), because in other case after reaching 0x0000000100000000 all off-chain transactions with timelocks around 0x00000000ffffffff will be additionally timelocked for the next N years. The same is needed for each OP_CHECKLOCKTIMEVERIFY, maybe pushing high 32 bits before the currently used value will solve that (and assuming zero if there is only some 32-bit value). On 2021-10-15 23:48:59 user yanma...@cock.li wrote: > It's well-known. Nobody really cares, because it's so far off. Not possible to do by softfork, no. It is possible to do by something that becomes a hardfork in 80 years, though, which is probably good enough. I proposed a solution, but nobody was really interested. Let's see if anyone bites now. --- Subject: Suggestion: Solve year 2106 problem by taking timestamps mod 2^32 To Bitcoin Protocol Discussion Date 2020-09-19 12:36 Message Body Currently, Bitcoin's timestamp rules are as follows: 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) Thus, Bitcoin will "die" on or about 2106-02-07, when there is no timestamp below 2^32 that exceeds the median of the last 11 blocks. If the rules were changed to the following, this problem would be solved: 1. The block timestamp plus k*2^32 may not be lower than the median of the last 11 blocks' 2. The block timestamp plus k*2^32 may not be greater than the current time plus two hours 3. k is an integer, whose value must be the same for the calculations of Rule 1 and Rule 2 This would cause a hardfork in the year 2106, which is approximately 85.5 years from now, by which time 95% of nodes would hopefully have updated. Another proposed solution is 64-bit timestamps. They would break compatibility with other software that has specific expectations of header fields, like ASICs' firmware. They would also cause a hardfork before the date of timestamp overflow. I thus believe them to be a less appropriate solution. What do you think of this idea? Is it worth a BIP? On 2021-10-13 19:16, vjudeu via bitcoin-dev wrote: > It seems that Bitcoin Core will stop working in 2038 because of > assertion checking if the current time is non-negative. Also, the > whole chain will halt after reaching median time 0xffffffff in 2106. > More information: https://bitcointalk.org/index.php?topic=5365359.0 > > I wonder if that kind of issues are possible to fix in a soft-fork > way. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
