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
|
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id B8840C000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 16 Oct 2021 09:06:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id A789E83417
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 16 Oct 2021 09:06:29 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_H2=-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 N7viyx3kJpsQ
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 16 Oct 2021 09:06:28 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo106.poczta.onet.pl (smtpo106.poczta.onet.pl
[213.180.149.159])
by smtp1.osuosl.org (Postfix) with ESMTPS id 305D783404
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 16 Oct 2021 09:06:27 +0000 (UTC)
Received: from pmq3v.m5r2.onet (pmq3v.m5r2.onet [10.174.32.69])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4HWcgw2ZRLzlgF7X;
Sat, 16 Oct 2021 11:06:20 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
t=1634375180; bh=4uwrC4+IY2hH6c4pLPhGtbeX43v56htnm8Dm5t3i+LY=;
h=From:To:In-Reply-To:Date:Subject:From;
b=Juvp+Z56T1bUDQIQStOBlt2KwAumCjc/NUtsVCVj2aU2moNFmkXSDunaV/4zIRMy8
fv+NlLDl2MySWvOj9ciOlSEMtsHXyBw7aMxrPCFwDHHNv94fiJWLM8lSg4Dj+Q9nWN
urLIfIjJ7pXBP9uTllbJGnahQE9cpS+lQpXSbMac=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.13.16] by pmq3v.m5r2.onet via HTTP id ;
Sat, 16 Oct 2021 11:06:20 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, "yanmaani@cock.li" <yanmaani@cock.li>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <nSiUl71p9JyISxvRJ3Jq71zNahe-rpanbFFv1MSHSk7rUKjq36yD7vmrJQ5Pnh5oUdDAFflgSzbCE5KK7RacFRepvjqFc9xp9qT7hU-twXA=@protonmail.com>
Date: Sat, 16 Oct 2021 11:06:17 +0200
Message-Id: <143903239-0c7634127ba6ddee7e69b14740b993cd@pmq3v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.13.16;PL;3
X-Mailman-Approved-At: Sat, 16 Oct 2021 18:57:54 +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 09:06:29 -0000
> What happens if a series of blocks has a timestamp of 0xFFFFFFFF at the a=
ppropriate time?
The chain will halt for all old clients, because there is no 32-bit value g=
reater than 0xffffffff.
> 1. Is not violated, since "not lower than" means "greater than or equal t=
o"
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.c=
om/bitcoin/bitcoin/blob/6f0cbc75be7644c276650fd98bfdb6358b827399/src/valida=
tion.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 poi=
nt to some time around 1970, so for old clients two rules are violated at t=
he same time.
> 3. Is not violated since 0xFFFFFFFF < 0x100000000.
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's why I think new timestamps should be pla=
ced in the coinbase transaction. But that still does not solve chain haltin=
g 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, 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.
Example from https://bitcointalk.org/index.php?topic=3D5365359.0
submitblock 0100000006226e46111a0b59caaf126043eb5bbf28c34f3a5e332a1fc7b2b73=
cf188910f3663c0de115e2239e05df4df9c4bfa01b8e843aaf5dae590cac1d9bac0d44c0fff=
ffffffffff7f200100000001020000000001010000000000000000000000000000000000000=
000000000000000000000000000ffffffff03510101ffffffff0200f2052a010000001976a9=
1462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac0000000000000000266a24aa21a9e=
de2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000=
000000000000000000000000000000000000000000000000000000000000000000
null
generatetoaddress 1 mpXwg4jMtRhuSpVq4xS3HFHmCmWp9NyGKt
CreateNewBlock: TestBlockValidity failed: time-too-old, block's timestamp i=
s 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 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)
What happens if a series of blocks has a timestamp of 0xFFFFFFFF at the app=
ropriate 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 0x=
FFFFFFFF
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 coinbase transa=
ction, 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 v1 if t=
he legacy v`nLockTime` is at the maximum seconds-timelock possible.
Regards,
ZmnSCPxj
|
