1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
Return-Path: <yanmaani@cock.li>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 72D44C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 12:44:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 5F46A20134
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 12:44:55 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id WpEWSklRkZN7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 12:44:53 +0000 (UTC)
X-Greylist: delayed 00:08:01 by SQLgrey-1.7.6
Received: from mail.cock.li (mail.cock.li [37.120.193.124])
by silver.osuosl.org (Postfix) with ESMTPS id 9C4342010F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 12:44:53 +0000 (UTC)
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.li; s=mail;
t=1600519007; bh=DACcdygWLylFEDVz6Hk9oB7JI2Z6BbL5IqkcqtzWXe0=;
h=Date:From:To:Subject:From;
b=WufS5gK1xWGVUvC4IuO/yIBjonJeq5YYwQfghnTQIRH7+Ga5NOFXIYnG43aHmNm0g
+GGXScsz6avLrTJGixRnT6NnMyF3iGoQHzZAk61/5EoZ15A7+yNcM7uTBPJwLwxiEb
gMz0AEsfyx2mnwuVkwHMNI+EcvumiU7xHzsfTmOZIYZ7CpG2ZkMMTYGpLyWoJouBnS
7PVGadgqYMZ3Df7GmL2gqNFekodtvCi3hvOW5Mg+2jR8hf7LskA/mwG2mw8z02eCTU
Me57+q5c0uGYe/S4e3x3xAzYwuQP/4GziJymckU0ejZP+ACaDVKhG7eoCSFaVC1VfS
dNI4seyHjVDHA==
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Sat, 19 Sep 2020 12:36:47 +0000
From: yanmaani@cock.li
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <42c7e76c023b403a9e99d29a1836b53e@cock.li>
X-Sender: yanmaani@cock.li
User-Agent: Roundcube Webmail/1.3.10
X-Mailman-Approved-At: Sat, 19 Sep 2020 13:08:33 +0000
Subject: [bitcoin-dev] Suggestion: Solve year 2106 problem by taking
timestamps mod 2^32
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Sep 2020 12:44:55 -0000
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?
|
