📅 Original date posted:2020-09-19
📝 Original message: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?
yanmaani at cock.li [ARCHIVE] /
npub13a…9uc29
2023-06-07 18:27:02
in reply to nevent1q…jlw4
Author Public Key
npub13adulxazm6ydmpm6vuhk9xjudfa7h0k687j3xfzjrcpcv0v0uz2qz9uc29Published at
2023-06-07 18:27:02Event JSON
{
"id": "c914c7c9d045368bf26d48898568a8d3dc35a1b62f0c3133f14fde686fce0895",
"pubkey": "8f5bcf9ba2de88dd877a672f629a5c6a7bebbeda3fa51324521e03863d8fe094",
"created_at": 1686162422,
"kind": 1,
"tags": [
[
"e",
"51cb7997025af19d06e1ef2d97abb5dc180b5925982c90dbbe4b6ebecca10ec3",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2020-09-19\n📝 Original message:Currently, 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?",
"sig": "69b2a8097f2bc8f9701948cd6bc4945036d229208ad77bfac151abd85530ad053d2f5153a88bf629b1578d0e76821fb81ffb3c3975380e5a38f5174aafe07a02"
}