* [bitcoin-dev] Suggestion: Solve year 2106 problem by taking timestamps mod 2^32
@ 2020-09-19 12:36 yanmaani
2020-10-16 21:58 ` Pieter Wuille
0 siblings, 1 reply; 2+ messages in thread
From: yanmaani @ 2020-09-19 12:36 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
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?
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [bitcoin-dev] Suggestion: Solve year 2106 problem by taking timestamps mod 2^32
2020-09-19 12:36 [bitcoin-dev] Suggestion: Solve year 2106 problem by taking timestamps mod 2^32 yanmaani
@ 2020-10-16 21:58 ` Pieter Wuille
0 siblings, 0 replies; 2+ messages in thread
From: Pieter Wuille @ 2020-10-16 21:58 UTC (permalink / raw)
To: yanmaani, Bitcoin Protocol Discussion
On Saturday, September 19, 2020 5:36 AM, yanmaani--- via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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:
>
> 4. The block timestamp plus k*2^32 may not be lower than the median of
> the last 11 blocks'
>
> 5. The block timestamp plus k*2^32 may not be greater than the current
> time plus two hours
>
> 6. k is an integer, whose value must be the same for the calculations of
> Rule 1 and Rule 2
I believe that is equivalent to: we treat block headers (as abstract data
structure) as having a 64-bit timestamp, which have the requirement that
the difference between the timestamp and the median timestamp of the past 11
blocks is at least one and at most 2^32 (I don't think we need to support
less than 6 blocks per 136 years).
On serialization, only the lower 32 bit are encoded. On deserialization,
the higher 32 bits are set equal to that of the median of the past 11 blocks.
If that violates the rule above, set it one higher.
That's in line of how I'd expect this will eventually be addressed. There is
no rush, of course.
> What do you think of this idea? Is it worth a BIP?
Probably, at some point.
Cheers,
--
Pieter
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-10-16 21:58 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-19 12:36 [bitcoin-dev] Suggestion: Solve year 2106 problem by taking timestamps mod 2^32 yanmaani
2020-10-16 21:58 ` Pieter Wuille
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox