public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: yanmaani@cock.li
To: vjudeu@gazeta.pl,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
Date: Fri, 15 Oct 2021 15:44:59 +0000	[thread overview]
Message-ID: <5978620b3db064897840b6170eed25d2@cock.li> (raw)
In-Reply-To: <50769965-423dd279413d4dba11ba459cbd98387b@pmq6v.m5r2.onet>

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


  parent reply	other threads:[~2021-10-15 15:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-13 19:16 [bitcoin-dev] Year 2038 problem and year 2106 chain halting vjudeu
2021-10-15 15:27 ` James Lu
2021-10-17  8:19   ` Kate Salazar
2021-10-17 22:38   ` damian
2021-10-15 15:44 ` yanmaani [this message]
2021-10-15 22:22   ` vjudeu
2021-10-17 15:14     ` yanmaani
2021-10-17 15:46       ` Kate Salazar
2021-10-18  2:55         ` yanmaani
2021-10-15 23:01   ` ZmnSCPxj
2021-10-16  9:06     ` vjudeu
2021-10-16 20:37       ` David Bakin
2021-10-16 21:34         ` Kate Salazar
2021-10-16 23:23       ` ZmnSCPxj
2021-10-17  7:24 vjudeu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5978620b3db064897840b6170eed25d2@cock.li \
    --to=yanmaani@cock.li \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=vjudeu@gazeta.pl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox