From: yanmaani@cock.li
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Suggestion: Solve year 2106 problem by taking timestamps mod 2^32
Date: Sat, 19 Sep 2020 12:36:47 +0000 [thread overview]
Message-ID: <42c7e76c023b403a9e99d29a1836b53e@cock.li> (raw)
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?
next reply other threads:[~2020-09-19 12:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-19 12:36 yanmaani [this message]
2020-10-16 21:58 ` [bitcoin-dev] Suggestion: Solve year 2106 problem by taking timestamps mod 2^32 Pieter Wuille
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=42c7e76c023b403a9e99d29a1836b53e@cock.li \
--to=yanmaani@cock.li \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/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