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

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

[vjudeu]

> Then starting at Unix Epoch 0x80000000, post-softfork nodes just increment the timestamp by 1 on each new block.

It is possible to go even faster. The fastest rate is something like that, if you assume the time in the Genesis Block is zero:

0 1 2 2 3 3 3 3 4 4 4 4 4 4 5 5 5 5 5 5 6 ...

Then you can increment timestamps once per 6 blocks, that means x3600 increase, but then the difficulty is always multiplied by four, so you have to increase time once per difficulty change to keep it on real level, then it will wave between being multiplied by 4 and by 0.25.

On 2021-10-17 01:23:24 user ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> Good morning vjudeu,

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

Then starting at Unix Epoch 0x80000000, post-softfork nodes just increment the timestamp by 1 on each new block.
This just kicks the can since that then imposes a limit on the maximum number of blocks, but at least the unit is now ~10 minutes instead of 1 second, a massive x600 increase in the amount of time we are forced to hardfork.

On the other hand, this does imply that the difficulty calculation will become astronomically and ludicrously high, since pre-softfork nodes will think that blocks are arriving at the rate of 1 per second, so ...

Regards,
ZmnSCPxj

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

[vjudeu]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 362 bytes --]

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

[James Lu]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

Making Bitcoin function after 2038 is by definition a hard fork

I feel if we do HF, we should bundle other HF changes with it...

On Wed, Oct 13, 2021 at 5:19 PM vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> 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
>

[-- Attachment #2: Type: text/html, Size: 1680 bytes --]

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

[Kate Salazar]

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

There is a hard fork wishlist:

https://en.bitcoin.it/wiki/Hardfork_Wishlist

Note last update is somewhat old.

Cheers.

On Sat, Oct 16, 2021 at 12:49 AM James Lu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Making Bitcoin function after 2038 is by definition a hard fork
>
> I feel if we do HF, we should bundle other HF changes with it...
>
> On Wed, Oct 13, 2021 at 5:19 PM vjudeu via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> 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
>

[-- Attachment #2: Type: text/html, Size: 2699 bytes --]

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

[damian]

Good Afternoon,

I am certain that as soon as we identify solutions they should be 
implemented. Basic life skills assert that procrastination is always a 
form of failure, where we could have realised and accomplished further 
yet we waited and in our present state could not ascertain what was in 
our benefit.

KING JAMES HRMH
Great British Empire

Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills

et al.


Willtech
www.willtech.com.au
www.go-overt.com
duigco.org DUIGCO API
and other projects


m. 0487135719
f. +61261470192


This email does not constitute a general advice. Please disregard this 
email if misdelivered.
On 2021-10-15 08:27, James Lu via bitcoin-dev wrote:
> Making Bitcoin function after 2038 is by definition a hard fork
> 
> I feel if we do HF, we should bundle other HF changes with it...
> 
> On Wed, Oct 13, 2021 at 5:19 PM vjudeu via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> 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

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

[yanmaani]

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

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

[vjudeu]

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 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=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

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

[yanmaani]

What, no. The `k` value is calculated implicitly, because there's only 
one value of it that could ever be valid - if `k` is 1 too small, we're 
70 years too far back, and then the block will violate median of last 
11. If `k` is 1 too large, we're 70 years too far in the future, then 
the block will violate 2 hour rule. Nothing is added to coinbase or 
anywhere else.

It's possible that you'd need some extra logic for locktime, yes, but it 
would only be a problem in very special cases. Worst-case, you'll have 
to use block time locking in the years around the switch, or softfork in 
64-bit locking.

But unless I'm missing something, 32-bit would be enough, you just 
wouldn't be able to locktime something past the timestamp for the 
switch. After the switchover, everything would be back to normal.

This is a hardfork, yes, but it's a hardfork that kicks in way into the 
future. And because it's a hardfork, you might as well do anything, as 
long as it doesn't change anything now.

On 2021-10-15 22:22, vjudeu@gazeta.pl wrote:
> 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).

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

[Kate Salazar]

[-- Attachment #1: Type: text/plain, Size: 3104 bytes --]

Hi yanmaani

On Sun, Oct 17, 2021 at 5:28 PM yanmaani--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> What, no. The `k` value is calculated implicitly, because there's only
> one value of it that could ever be valid - if `k` is 1 too small, we're
> 70 years too far back, and then the block will violate median of last
> 11. If `k` is 1 too large, we're 70 years too far in the future, then
> the block will violate 2 hour rule. Nothing is added to coinbase or
> anywhere else.
>
> It's possible that you'd need some extra logic for locktime, yes, but it
> would only be a problem in very special cases. Worst-case, you'll have
> to use block time locking in the years around the switch, or softfork in
> 64-bit locking.
>
> But unless I'm missing something, 32-bit would be enough, you just
> wouldn't be able to locktime something past the timestamp for the
> switch. After the switchover, everything would be back to normal.
>
> This is a hardfork, yes, but it's a hardfork that kicks in way into the
> future. And because it's a hardfork, you might as well do anything, as
> long as it doesn't change anything now.
>

"Anything" is quite a word.
Ideally, hard fork requires upgrading every node that can be upgraded,
or at least have the node operator's consent to lose the node (for every
node that can't be upgraded).


>
> On 2021-10-15 22:22, vjudeu@gazeta.pl wrote:
> > 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).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 4191 bytes --]

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

[yanmaani]

Well, it's the right word. If you're going to do a hardfork by changing 
the timestamp definition, you're already doing a hardfork. At that 
point, you've already crossed the Rubicon and might as well put in any 
other necessary changes (e.g. to transaction locking), because it will 
be as much of a hardfork either way.

The important bit here is "as long as it doesn't change anything now" - 
this is indeed a hardfork, but it's a timestamp-activated hardfork that 
triggers in 2106. Until that point, it has absolutely no bearing on 
consensus rules (as opposed to the other proposals, which are at least a 
soft-fork today).

I understand that there's some problems in getting consensus for forks, 
but surely we can agree that everyone will update their Bitcoin at least 
once in the next 85 years? (If they don't, they're doomed anyway.)

On 2021-10-17 15:46, Kate Salazar wrote:
> Hi yanmaani
> 
...
>> This is a hardfork, yes, but it's a hardfork that kicks in way into
>> the
>> future. And because it's a hardfork, you might as well do anything,
>> as
>> long as it doesn't change anything now.
> 
> "Anything" is quite a word.
> Ideally, hard fork requires upgrading every node that can be upgraded,
> 
> or at least have the node operator's consent to lose the node (for
> every
> node that can't be upgraded).
> 
...
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[ZmnSCPxj]

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

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

[vjudeu]

> 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

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

[David Bakin]

[-- Attachment #1: Type: text/plain, Size: 4592 bytes --]

yes but ... just for the sake of argument ... if a change such as this
wraparound interpretation is made anytime in the next 5 years it'll be over
a *decade after that *before any wrapped-around timestamp is legitimately
mined ... and by then nobody will be running incompatible (decade old) node
software (especially since it would mean that a decade had gone by without
a *single* consensus change ... seems very unlikely).

On Sat, Oct 16, 2021 at 11:57 AM vjudeu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > 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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 5632 bytes --]

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

[Kate Salazar]

[-- Attachment #1: Type: text/plain, Size: 5371 bytes --]

Hi, BIP 42 is a code base consensus soft fork that at the time of
activation does not really manifest as a fork because nobody is running any
code not already applying it. Can a similar thing be done in 17 years? (I
haven't really made sense of this year 2038 problem, I don't know or
understand what is required if there's something to be done).
Cheers!

On Sat, Oct 16, 2021 at 11:00 PM David Bakin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> yes but ... just for the sake of argument ... if a change such as this
> wraparound interpretation is made anytime in the next 5 years it'll be over
> a *decade after that *before any wrapped-around timestamp is legitimately
> mined ... and by then nobody will be running incompatible (decade old) node
> software (especially since it would mean that a decade had gone by without
> a *single* consensus change ... seems very unlikely).
>
> On Sat, Oct 16, 2021 at 11:57 AM vjudeu via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> > 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
>>
>>
>> _______________________________________________
>> 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
>

[-- Attachment #2: Type: text/html, Size: 6812 bytes --]

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

[ZmnSCPxj]

Good morning vjudeu,

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

Then starting at Unix Epoch 0x80000000, post-softfork nodes just increment the timestamp by 1 on each new block.
This just kicks the can since that then imposes a limit on the maximum number of blocks, but at least the unit is now ~10 minutes instead of 1 second, a massive x600 increase in the amount of time we are forced to hardfork.

On the other hand, this does imply that the difficulty calculation will become astronomically and ludicrously high, since pre-softfork nodes will think that blocks are arriving at the rate of 1 per second, so ...

Regards,
ZmnSCPxj