Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: vjudeu@gazeta.pl
To: yanmaani@cock.li,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <5978620b3db064897840b6170eed25d2@cock.li>
Date: Sat, 16 Oct 2021 00:22:00 +0200
Message-Id: <143289360-eb35e705fded3eb4175a6f8d7669b3a0@pmq5v.m5r2.onet>
Subject: Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
Precedence: list

Your solution seems to solve the problem of chain halting, but there are mo=
re issues. For example: if you have some time modulo 2^32, then you no long=
er know if timestamp zero is related to 1970 or 2106 or some higher year. Y=
our "k" value representing in fact the most significant 32 bits of 64-bit t=
imestamp 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 ag=
ain in 0x00000001badc0ded, the same for timelocked outputs.

So, I think your "k" value should be added to the coinbase transaction, the=
n you can combine two 32-bit values, the lower bits from the block header a=
nd the higher bits from the coinbase transaction. Also, adding your "k" val=
ue transaction nLockTime field is needed (maybe in a similar way as transac=
tion witness was added in Segwit), because in other case after reaching 0x0=
000000100000000 all off-chain transactions with timelocks around 0x00000000=
ffffffff will be additionally timelocked for the next N years. The same is =
needed for each OP_CHECKLOCKTIMEVERIFY, maybe pushing high 32 bits before t=
he 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 yanmaani@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=3D5365359.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