summaryrefslogtreecommitdiff
path: root/14/e0085977bf9ccfb0d3b46e46d5f96cce576779
blob: 05ec355f114c6e55e5482834cb3784d84505f488 (plain)
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
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
Return-Path: <mercedes.catherine.salazar@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 88B13C000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 16 Oct 2021 21:34:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 71CCC4034A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 16 Oct 2021 21:34:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 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,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id V2kaNR35_5Ez
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 16 Oct 2021 21:34:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com
 [IPv6:2607:f8b0:4864:20::b2d])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 09D4340342
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 16 Oct 2021 21:34:44 +0000 (UTC)
Received: by mail-yb1-xb2d.google.com with SMTP id v195so235528ybb.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 16 Oct 2021 14:34:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=587IPSUIIKx+yi7Vv3+yEZu3wrX0MBKGlKvSKaE8Wck=;
 b=pSWQy6HbKmmzrj7ef29qClvcjXjwyPkP/kSvtTyywxQgmcoS8+KjMIk4EclFhjjA7m
 suj/K8Viv4ip990j9PebJEGlFApm3OZY/U1T+0G7Mn/26eZhiP0kA3CSA3wXbyWsHuA5
 mKhne8w1ulnohBZTBapk4JZJf9CPTuQp+TB0VlgvKCCTXAgSYszzNiLMZ0B+0dOtxyQV
 24tgpG6cVrKLxjx1HmrVg3csDrzTitoYGki9EClfRznvJRK3frCSACAMcJeyT2Ayp589
 43M+8SMTpwC1GCpxNzhz7uxXOnbUEPto8v9vdN777St3lRpQfUUpg1gmmmY/AnPMSXA8
 sNuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=587IPSUIIKx+yi7Vv3+yEZu3wrX0MBKGlKvSKaE8Wck=;
 b=5nBeTFJvto0FTvBQ/GACYFyLikHrDiD6yoPYg5lIe8Fm8SEYcZU991UCiwPzJovDQn
 pS6OC+leqrp+pkByfI8f4hODiqmuwJ0OJbHBQHAmN9Oa3wictxTSDhCppPHFAWamorow
 FJForYCE49AkdvtzXdJjOdQTINoArpf6wABgER9ZnDcmcN5eZoyizx5FLgXCc8cZH6A5
 e+kdWfPaL7yQq6qQblaY7NSXnj5LzJynBCAM+Vqrlb5EwssZ7V4AXbQFBRIf+ZMMtekQ
 Yebh84z7PffSpkaH+I6bMUM287vOjY0VJCQ/cwr0yVzowF73w6GagmfL1c4gfT8nR6gZ
 3V3A==
X-Gm-Message-State: AOAM530Lh6pvyauGkr4wf8yaLyvwsnj8TJUJNoId6i+mn6AymNJNVSGz
 DBQylOsPNBzbiNQdQoExyyXarI4kN+v7ghsjRU2Ym2/EiImP15lH
X-Google-Smtp-Source: ABdhPJzIo69vhyoEd5PyqlynrCR6S8RpVwfrhz9zbTze6rh4ZrqX9rVm3RNicx9Q81vMVxd9pnivMtzCGBz/pkBe+ng=
X-Received: by 2002:a25:ae92:: with SMTP id b18mr21121503ybj.220.1634420083931; 
 Sat, 16 Oct 2021 14:34:43 -0700 (PDT)
MIME-Version: 1.0
References: <nSiUl71p9JyISxvRJ3Jq71zNahe-rpanbFFv1MSHSk7rUKjq36yD7vmrJQ5Pnh5oUdDAFflgSzbCE5KK7RacFRepvjqFc9xp9qT7hU-twXA=@protonmail.com>
 <143903239-0c7634127ba6ddee7e69b14740b993cd@pmq3v.m5r2.onet>
 <CAF-gu8h0BJOnHUjdjLPh4_pQ0j1Xxuwb5axQnNetk_ctTNo-4Q@mail.gmail.com>
In-Reply-To: <CAF-gu8h0BJOnHUjdjLPh4_pQ0j1Xxuwb5axQnNetk_ctTNo-4Q@mail.gmail.com>
From: Kate Salazar <mercedes.catherine.salazar@gmail.com>
Date: Sat, 16 Oct 2021 23:34:32 +0200
Message-ID: <CAHiDt8CnLWkze8HTdPvh97n-U+A+WZyET1jNHxCGcoLR3K8opg@mail.gmail.com>
To: David Bakin <david@bakins-bits.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000843ca505ce7f142a"
X-Mailman-Approved-At: Sat, 16 Oct 2021 21:48:57 +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: Sat, 16 Oct 2021 21:34:46 -0000

--000000000000843ca505ce7f142a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi, BIP 42 is a code base consensus soft fork that at the time of
activation does not really manifest as a fork because nobody is running any
code not already applying it. Can a similar thing be done in 17 years? (I
haven't really made sense of this year 2038 problem, I don't know or
understand what is required if there's something to be done).
Cheers!

On Sat, Oct 16, 2021 at 11:00 PM David Bakin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> yes but ... just for the sake of argument ... if a change such as this
> wraparound interpretation is made anytime in the next 5 years it'll be ov=
er
> a *decade after that *before any wrapped-around timestamp is legitimately
> mined ... and by then nobody will be running incompatible (decade old) no=
de
> software (especially since it would mean that a decade had gone by withou=
t
> a *single* consensus change ... seems very unlikely).
>
> On Sat, Oct 16, 2021 at 11:57 AM vjudeu via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> > What happens if a series of blocks has a timestamp of 0xFFFFFFFF at th=
e
>> appropriate time?
>>
>> The chain will halt for all old clients, because there is no 32-bit valu=
e
>> greater than 0xffffffff.
>>
>> > 1. Is not violated, since "not lower than" means "greater than or equa=
l
>> to"
>>
>> No, because it has to be strictly "greater than" in the Bitcoin Core
>> source code, it is rejected when it is "lower or equal to", see:
>> https://github.com/bitcoin/bitcoin/blob/6f0cbc75be7644c276650fd98bfdb635=
8b827399/src/validation.cpp#L3089-L3094
>>
>> > 2. Is not violated, since it would be a past actual real time.
>>
>> If the current time is 0x0000000100000000, then the lowest 32 bits will
>> point to some time around 1970, so for old clients two rules are violate=
d
>> at the same time.
>>
>> > 3. Is not violated since 0xFFFFFFFF < 0x100000000.
>>
>> This is hard to change, because 32-bit timestamps are included in block
>> headers, so using any wider data type here will make it
>> hardware-incompatible and will cause a hard-fork. That's why I think new
>> timestamps should be placed in the coinbase transaction. But that still
>> does not solve chain halting problem.
>>
>> To test chain halting, all that is needed is starting regtest and
>> producing one block with 0xffffffff timestamp, just after the Genesis
>> Block. Then, median time is equal to 0xffffffff and adding any new block=
s
>> is no longer possible. The only soft-fork solution I can see require
>> overwriting that block.
>>
>> Example from https://bitcointalk.org/index.php?topic=3D5365359.0
>>
>> submitblock
>> 0100000006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73cf188910f=
3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0ffffffffffff=
f7f200100000001020000000001010000000000000000000000000000000000000000000000=
000000000000000000ffffffff03510101ffffffff0200f2052a010000001976a91462e907b=
15cbf27d5425399ebf6f0fb50ebb88f1888ac0000000000000000266a24aa21a9ede2f61c3f=
71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000=
000000000000000000000000000000000000000000000000000000000
>> null
>> generatetoaddress 1 mpXwg4jMtRhuSpVq4xS3HFHmCmWp9NyGKt
>> CreateNewBlock: TestBlockValidity failed: time-too-old, block's timestam=
p
>> is too early (code -1)
>>
>> I don't know any timestamp that can be used in any next block and
>> accepted by old nodes.
>>
>> On 2021-10-16 01:01:54 user ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>> > Good morning yanmaani,
>>
>>
>> > It's well-known. Nobody really cares, because it's so far off. Not
>> > possible to do by softfork, no.
>>
>> I think it is possible by softfork if we try hard enough?
>>
>>
>> > 1.  The block timestamp may not be lower than the median of the last 1=
1
>> >     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)
>>
>> What happens if a series of blocks has a timestamp of 0xFFFFFFFF at the
>> appropriate time?
>>
>> In that case:
>>
>> 1.  Is not violated, since "not lower than" means "greater than or equal
>> to", and after a while the median becomes 0xFFFFFFFF and 0xFFFFFFFF =3D=
=3D
>> 0xFFFFFFFF
>> 2.  Is not violated, since it would be a past actual real time.
>> 3.  Is not violated since 0xFFFFFFFF < 0x100000000.
>>
>> In that case, we could then add an additional rule, which is that a
>> 64-bit (or 128-bit, or 256-bit) timestamp has to be present in the coinb=
ase
>> transaction, with similar rules except translated to 64-bit/128-bit/256-=
bit.
>>
>> Possibly a similar scheme could be used for `nLockTime`; we could put a
>> 64-bit `nLockTime64` in that additional signed block in Taproot SegWit v=
1
>> if the legacy v`nLockTime` is at the maximum seconds-timelock possible.
>>
>> Regards,
>> ZmnSCPxj
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000843ca505ce7f142a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi, BIP 42 is a code base consensus soft fork that at the =
time of activation does not really manifest as a fork because nobody is run=
ning any code not already applying it. Can a similar thing be done in 17 ye=
ars? (I haven&#39;t really made sense of this year 2038 problem, I don&#39;=
t know or understand what is required=C2=A0if there&#39;s something to be d=
one).<div>Cheers!</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Sat, Oct 16, 2021 at 11:00 PM David Bakin via bit=
coin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr">yes but ... just for the =
sake of argument ... if a change such as this wraparound interpretation is =
made anytime in the next 5 years it&#39;ll be over a <i>decade after that=
=C2=A0</i>before any wrapped-around timestamp is legitimately mined ... and=
 by then nobody will be running incompatible (decade old) node software (es=
pecially since it would mean that a decade had gone by without a <i>single<=
/i>=C2=A0consensus=C2=A0change ... seems very unlikely).</div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Oct 16, 202=
1 at 11:57 AM vjudeu via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">&gt; What happens if a series of blocks has a timestamp of 0xFFFFFFFF at=
 the appropriate time?<br>
<br>
The chain will halt for all old clients, because there is no 32-bit value g=
reater than 0xffffffff.<br>
<br>
&gt; 1. Is not violated, since &quot;not lower than&quot; means &quot;great=
er than or equal to&quot;<br>
<br>
No, because it has to be strictly &quot;greater than&quot; in the Bitcoin C=
ore source code, it is rejected when it is &quot;lower or equal to&quot;, s=
ee: <a href=3D"https://github.com/bitcoin/bitcoin/blob/6f0cbc75be7644c27665=
0fd98bfdb6358b827399/src/validation.cpp#L3089-L3094" rel=3D"noreferrer" tar=
get=3D"_blank">https://github.com/bitcoin/bitcoin/blob/6f0cbc75be7644c27665=
0fd98bfdb6358b827399/src/validation.cpp#L3089-L3094</a><br>
<br>
&gt; 2. Is not violated, since it would be a past actual real time.<br>
<br>
If the current time is 0x0000000100000000, then the lowest 32 bits will poi=
nt to some time around 1970, so for old clients two rules are violated at t=
he same time.<br>
<br>
&gt; 3. Is not violated since 0xFFFFFFFF &lt; 0x100000000.<br>
<br>
This is hard to change, because 32-bit timestamps are included in block hea=
ders, so using any wider data type here will make it hardware-incompatible =
and will cause a hard-fork. That&#39;s why I think new timestamps should be=
 placed in the coinbase transaction. But that still does not solve chain ha=
lting problem.<br>
<br>
To test chain halting, all that is needed is starting regtest and producing=
 one block with 0xffffffff timestamp, just after the Genesis Block. Then, m=
edian time is equal to 0xffffffff and adding any new blocks is no longer po=
ssible. The only soft-fork solution I can see require overwriting that bloc=
k.<br>
<br>
Example from <a href=3D"https://bitcointalk.org/index.php?topic=3D5365359.0=
" rel=3D"noreferrer" target=3D"_blank">https://bitcointalk.org/index.php?to=
pic=3D5365359.0</a><br>
<br>
submitblock 0100000006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73=
cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0fff=
ffffffffff7f200100000001020000000001010000000000000000000000000000000000000=
000000000000000000000000000ffffffff03510101ffffffff0200f2052a010000001976a9=
1462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac0000000000000000266a24aa21a9e=
de2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000=
000000000000000000000000000000000000000000000000000000000000000000<br>
null<br>
generatetoaddress 1 mpXwg4jMtRhuSpVq4xS3HFHmCmWp9NyGKt<br>
CreateNewBlock: TestBlockValidity failed: time-too-old, block&#39;s timesta=
mp is too early (code -1)<br>
<br>
I don&#39;t know any timestamp that can be used in any next block and accep=
ted by old nodes.<br>
<br>
On 2021-10-16 01:01:54 user ZmnSCPxj &lt;<a href=3D"mailto:ZmnSCPxj@protonm=
ail.com" target=3D"_blank">ZmnSCPxj@protonmail.com</a>&gt; wrote:<br>
&gt; Good morning yanmaani,<br>
<br>
<br>
&gt; It&#39;s well-known. Nobody really cares, because it&#39;s so far off.=
 Not<br>
&gt; possible to do by softfork, no.<br>
<br>
I think it is possible by softfork if we try hard enough?<br>
<br>
<br>
&gt; 1.=C2=A0 The block timestamp may not be lower than the median of the l=
ast 11<br>
&gt;=C2=A0 =C2=A0 =C2=A0blocks&#39;<br>
&gt;<br>
&gt; 2.=C2=A0 The block timestamp may not be greater than the current time =
plus two<br>
&gt;=C2=A0 =C2=A0 =C2=A0hours<br>
&gt;<br>
&gt; 3.=C2=A0 The block timestamp may not be greater than 2^32 (Sun, 07 Feb=
 2106<br>
&gt;=C2=A0 =C2=A0 =C2=A006:28:16 +0000)<br>
<br>
What happens if a series of blocks has a timestamp of 0xFFFFFFFF at the app=
ropriate time?<br>
<br>
In that case:<br>
<br>
1.=C2=A0 Is not violated, since &quot;not lower than&quot; means &quot;grea=
ter than or equal to&quot;, and after a while the median becomes 0xFFFFFFFF=
 and 0xFFFFFFFF =3D=3D 0xFFFFFFFF<br>
2.=C2=A0 Is not violated, since it would be a past actual real time.<br>
3.=C2=A0 Is not violated since 0xFFFFFFFF &lt; 0x100000000.<br>
<br>
In that case, we could then add an additional rule, which is that a 64-bit =
(or 128-bit, or 256-bit) timestamp has to be present in the coinbase transa=
ction, with similar rules except translated to 64-bit/128-bit/256-bit.<br>
<br>
Possibly a similar scheme could be used for `nLockTime`; we could put a 64-=
bit `nLockTime64` in that additional signed block in Taproot SegWit v1 if t=
he legacy v`nLockTime` is at the maximum seconds-timelock possible.<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000843ca505ce7f142a--