š
Original date posted:2021-10-15
š Original message: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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
yanmaani at cock.li [ARCHIVE] /
npub13aā¦9uc29
2023-06-07 23:00:07
in reply to nevent1qā¦6m5q
Author Public Key
npub13adulxazm6ydmpm6vuhk9xjudfa7h0k687j3xfzjrcpcv0v0uz2qz9uc29Published at
2023-06-07 23:00:07Event JSON
{
"id": "ff4ccadfc169890675496ea8c33f3ba34e2f5df3b54a94389a62cb1215f13acd",
"pubkey": "8f5bcf9ba2de88dd877a672f629a5c6a7bebbeda3fa51324521e03863d8fe094",
"created_at": 1686178807,
"kind": 1,
"tags": [
[
"e",
"c0e13d397dc71c2d737cbe4277ed0c11fb0c8d97302650a28ed4170c1d01b58d",
"",
"root"
],
[
"e",
"0f5fe9d37cf9de61023e3b42d89037ecceda1f2ab87e4d248a02f82205bcfcf4",
"",
"reply"
],
[
"p",
"e085c47d7498ebbbe7a51aebef47b9a2f0ec339510974ca35c361bd57d4fec1e"
]
],
"content": "š
Original date posted:2021-10-15\nš Original message:It's well-known. Nobody really cares, because it's so far off. Not \npossible to do by softfork, no. It is possible to do by something that \nbecomes a hardfork in 80 years, though, which is probably good enough.\n\nI proposed a solution, but nobody was really interested. Let's see if \nanyone bites now.\n\n---\n\nSubject: Suggestion: Solve year 2106 problem by taking timestamps mod \n2^32\nTo \tBitcoin Protocol Discussion\nDate \t2020-09-19 12:36\nMessage Body\nCurrently, Bitcoin's timestamp rules are as follows:\n\n1. The block timestamp may not be lower than the median of the last 11 \nblocks'\n2. The block timestamp may not be greater than the current time plus two \nhours\n3. The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106 \n06:28:16 +0000)\n\nThus, Bitcoin will \"die\" on or about 2106-02-07, when there is no \ntimestamp below 2^32 that exceeds the median of the last 11 blocks.\n\nIf the rules were changed to the following, this problem would be \nsolved:\n\n1. The block timestamp plus k*2^32 may not be lower than the median of \nthe last 11 blocks'\n2. The block timestamp plus k*2^32 may not be greater than the current \ntime plus two hours\n3. k is an integer, whose value must be the same for the calculations of \nRule 1 and Rule 2\n\nThis would cause a hardfork in the year 2106, which is approximately \n85.5 years from now, by which time 95% of nodes would hopefully have \nupdated.\n\nAnother proposed solution is 64-bit timestamps. They would break \ncompatibility with other software that has specific expectations of \nheader fields, like ASICs' firmware. They would also cause a hardfork \nbefore the date of timestamp overflow. I thus believe them to be a less \nappropriate solution.\n\nWhat do you think of this idea? Is it worth a BIP?\n\nOn 2021-10-13 19:16, vjudeu via bitcoin-dev wrote:\n\u003e It seems that Bitcoin Core will stop working in 2038 because of\n\u003e assertion checking if the current time is non-negative. Also, the\n\u003e whole chain will halt after reaching median time 0xffffffff in 2106.\n\u003e More information: https://bitcointalk.org/index.php?topic=5365359.0\n\u003e \n\u003e I wonder if that kind of issues are possible to fix in a soft-fork\n\u003e way.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "6cb2d8f3e127d41a7673808aeb6b4b2c74dc2fbb5814587d23126e98ea81cf0489dd042c8a5027f1fd8e13ef06980b968dea93493284a2fa7e400dce8a3a4fa2"
}