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
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 57DE4C000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Oct 2021 22:27:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 3A7CA83AC3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Oct 2021 22:27:13 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=gazeta.pl
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id CS4fbNp9m275
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Oct 2021 22:27:12 +0000 (UTC)
X-Greylist: delayed 00:05:02 by SQLgrey-1.8.0
Received: from o250.poczta.onet.pl (o250.poczta.onet.pl [213.180.142.250])
by smtp1.osuosl.org (Postfix) with ESMTPS id A04F683A99
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Oct 2021 22:27:11 +0000 (UTC)
Received: from pmq5v.m5r2.onet (pmq5v.m5r2.onet [10.174.35.25])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4HWLNS4jTdz1bJj;
Sat, 16 Oct 2021 00:22:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
t=1634336520; bh=N/P2Vykp/1HLXvqchC/3b5UrA4bqHDgR2p6T4JvI5Dg=;
h=From:To:In-Reply-To:Date:Subject:From;
b=oIleQC921sDelsoWC/y9SDIeBYe1DBDlIcsgzKppWtmQGCQD2kSQ7SSF2YjPS3P7a
QNArL14iIOx92AiZvdhBE1zZNMweRYjd1akLhZ8l4xOqU2qcdiVUycOGrpkgbpzQ6m
qYXGPfyBaVmPgOZvCeyz+L/m6c2G3K/tD8JUao5c=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.13.16] by pmq5v.m5r2.onet via HTTP id ;
Sat, 16 Oct 2021 00:22:00 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
To: yanmaani@cock.li,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <5978620b3db064897840b6170eed25d2@cock.li>
Date: Sat, 16 Oct 2021 00:22:00 +0200
Message-Id: <143289360-eb35e705fded3eb4175a6f8d7669b3a0@pmq5v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.13.16;PL;2
X-Mailman-Approved-At: Fri, 15 Oct 2021 22:48:22 +0000
Subject: Re: [bitcoin-dev] Year 2038 problem and year 2106 chain halting
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: Fri, 15 Oct 2021 22:27:13 -0000
Your solution seems to solve the problem of chain halting, but there are mo=
re issues. For example: if you have some time modulo 2^32, then you no long=
er know if timestamp zero is related to 1970 or 2106 or some higher year. Y=
our "k" value representing in fact the most significant 32 bits of 64-bit t=
imestamp has to be stored in all cases where time is used. If there is no "=
k", then zero should be used for backward compatibility. Skipping "k" could=
cause problems related to OP_CHECKLOCKTIMEVERIFY or nLockTime, because if =
some transaction was timestamped to 0xbadc0ded, then that transaction will =
be valid in 0x00000000badc0ded, invalid in 0x0000000100000000, and valid ag=
ain in 0x00000001badc0ded, the same for timelocked outputs.
So, I think your "k" value should be added to the coinbase transaction, the=
n you can combine two 32-bit values, the lower bits from the block header a=
nd the higher bits from the coinbase transaction. Also, adding your "k" val=
ue transaction nLockTime field is needed (maybe in a similar way as transac=
tion witness was added in Segwit), because in other case after reaching 0x0=
000000100000000 all off-chain transactions with timelocks around 0x00000000=
ffffffff will be additionally timelocked for the next N years. The same is =
needed for each OP_CHECKLOCKTIMEVERIFY, maybe pushing high 32 bits before t=
he currently used value will solve that (and assuming zero if there is only=
some 32-bit value).
On 2021-10-15 23:48:59 user yanmaani@cock.li wrote:
> 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=3D5365359.0
> =
> I wonder if that kind of issues are possible to fix in a soft-fork
> way.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
