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
|
Delivery-date: Sun, 25 Aug 2024 07:58:28 -0700
Received: from mail-yb1-f188.google.com ([209.85.219.188])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBC3PT7FYWAMRBC4NVW3AMGQEAN6XO3Q@googlegroups.com>)
id 1siEhI-0000i7-4W
for bitcoindev@gnusha.org; Sun, 25 Aug 2024 07:58:28 -0700
Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-e17bb508bb9sf3091990276.2
for <bitcoindev@gnusha.org>; Sun, 25 Aug 2024 07:58:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1724597901; x=1725202701; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:message-id:to:from:date:sender:from:to:cc:subject:date
:message-id:reply-to;
bh=CQE4NDK7XZhTp41hPyvZpGlCRZNr/sxdFSY7MRLiDNM=;
b=av7C9Bluf43xOnv/I9TJJ4aQaWCkjP+9OaTE+O8uoVLTMZIf8afIvXULlgRf5J5h8Q
lA/AjF5oERz+AfHawWg48PZUGBf8ctDmVbftlqB1ngDSG4D8fVFW6NryDAEWkSAwJ4Ws
Qj0nRtnSH34nwWQlWOxVTpH1qHMU5rRlawfDQyIKI/bzeIfoZ3cpF6YDq1OVkd4hTAT1
Czoib3EPuGkjesDyaBE/Q7ZRZFlLG/tsxrbuvV8JT7XjAdQk+Dq1edn4BYruypyjmBn5
AVOLa8i+qzsO+GggskyvBwyrrqJGRqWpybJT49im/4zhYpMBc6esga67aEByNDtPIGl/
K03A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1724597901; x=1725202701; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:message-id:to:from:date:from:to:cc:subject:date:message-id
:reply-to;
bh=CQE4NDK7XZhTp41hPyvZpGlCRZNr/sxdFSY7MRLiDNM=;
b=Rh9d1HwkzxXnNgUbP9eXisM9mKKuMTbckO1fV/2neYZoqeuGRzPUx6+A1ATteiAxto
9wjrzMvCd+4MXgEb4fJ6w3JzUlNJRigX0uBHJl+23kfWtD5thMQQX1mPLf1WyRqYe6c1
+OrAYecdjSh91tuUJQ1LpQsATwbTn0S3FRvftCAvgHkdHvusQkmd2SA4or6Yqljtj939
Ine8wWHM1bjiz3Xf7jS0nNvKGFUQZgIaqQKCxQk6yiyuQOVWyWqFZ5hMf5BElhwHNciy
KJ+gb1wwmII1dSJx3i8LcR0X34fgSRzT7b02223sILJtvW3uzv4EhVKlTPY2glMvLuxH
kSZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1724597901; x=1725202701;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:message-id:to:from:date:x-beenthere:x-gm-message-state
:sender:from:to:cc:subject:date:message-id:reply-to;
bh=CQE4NDK7XZhTp41hPyvZpGlCRZNr/sxdFSY7MRLiDNM=;
b=Zb90WwEfCzZYoVpfdB53WCct3pEkexY/8xor1D/AF3/W2sy8XM4Z0nzP3mZDLqLeQi
7JtUj9Jp1EH08uXtf1sAxZblhv4kaDO8NZum0JIAq/ntteXaDw3iaBB3sCzMBIUD6uIl
4Otu43HyiHtWfxCw+oWe7SaUOoEpsEYJ4SRKep5GHbm1A4yqJPBkh+wLhM1oIra2IhWO
lKc3MxMEtbAD2IJBl7diffM4Z94u+X/SJEhorBfARW6szGUo+6CPCzWyAydRsOIHM0lN
5riikvrMP2bVwwI0Xx5+8Uoq4YQvvWvb60aThan+Qs8Hf0RmiL9PLKjXyJuEpRjJwot6
ctpw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXwDCPivg5MCAXveaBu4nEIdkKuxiHs9UnEDInoNXlLBibwFuDGK5oP+63mN5MhpWzy1lYkuHY2U+aV@gnusha.org
X-Gm-Message-State: AOJu0YzLH2hjL3XesW9Rl5CNKxYtiXSsCMf3MVjD6Yq+RADoBlcqw4Op
gp7w5H0ucrGG1D2BIajz4iVXnkcLKa/51HM96CyZYOT7mY4LuDTB
X-Google-Smtp-Source: AGHT+IF7iQcBQ4Ys38YoXl0shf5kuUrUo45m7KUGFSp70vNBE3Eh3sFKU2jsAO5Y1O0TE163KSz29w==
X-Received: by 2002:a05:6902:2845:b0:e0b:fdc2:4df2 with SMTP id 3f1490d57ef6-e17a8e429f3mr9732175276.43.1724597901192;
Sun, 25 Aug 2024 07:58:21 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:6902:1209:b0:e16:3642:2a73 with SMTP id
3f1490d57ef6-e178bd4edf0ls2034885276.2.-pod-prod-04-us; Sun, 25 Aug 2024
07:58:19 -0700 (PDT)
X-Received: by 2002:a05:690c:660b:b0:62f:f535:f41 with SMTP id 00721157ae682-6c629345863mr5747647b3.9.1724597899185;
Sun, 25 Aug 2024 07:58:19 -0700 (PDT)
Received: by 2002:a05:690c:2a93:b0:64a:6fb4:b878 with SMTP id 00721157ae682-6c5b829a2f9ms7b3;
Sun, 25 Aug 2024 07:36:43 -0700 (PDT)
X-Received: by 2002:a05:690c:288d:b0:651:6e6f:32d2 with SMTP id 00721157ae682-6c629159b96mr70593397b3.43.1724596602657;
Sun, 25 Aug 2024 07:36:42 -0700 (PDT)
Date: Sun, 25 Aug 2024 07:36:42 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <e045e415-9f0b-4f90-9c65-3aeeecca785bn@googlegroups.com>
Subject: [bitcoindev] Timewarp fix, Mining software and Clocks
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_323898_313843232.1724596602482"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)
------=_Part_323898_313843232.1724596602482
Content-Type: multipart/alternative;
boundary="----=_Part_323899_106706459.1724596602482"
------=_Part_323899_106706459.1724596602482
Content-Type: text/plain; charset="UTF-8"
Hi list,
About fixing the timewarp attack, I think one aspect wasn't mentioned in
Pointsot's post
about consensus cleanup from few months ago is potentially the necessity to
have an upgrade of pool softwares. New consensus rule is the following "The
nTime field of each block whose height, mod 2016, is 0 must be greater than
or equal to the nTime field of the immediately prior block minus 600".
As it's noted in the cleanup bip, if the last block of the period timestamp
is in the
future, non upgraded miners mining the first block of the period could see
it orphaned
if the nTime field isn't adjusted accordingly. While this could arise
spontaneously from
unreliable local clocks, a malicious miner could deliberately exploit this
new behavior by
offsetting last block nTime field to one hour in the future (consensus rule
reminder: no
block more than 2 hours in the future), then next honest non-upgraded miner
could naively mine the first block of the next period which would be deemed
invalid by new consensus rules. Malicious miner, aware of the nTime
offsetting, gets an advantage to mine the first block of this period, which
would be accepted by all remaining network full-nodes. Assuming all network
wall clocks are well in sync, there is little risk for a malicious miner to
engage in such last block period nTime offsetting (scenario re-tested here
[0]).
New bitcoin core getblocktemplate code on testnet4 is adjusting the nTime
field for
each first period block compared to the last block nTime field minus 600s.
However,
this upgrade behavior is far from being ported in any other block template
providers
(e.g getblocktemplate other implementations, stratum v2) in the mining
ecosystem and
I don't know if it should be further documented or implemented (e.g
addendum to bip23 ?). E.g Stratum V2's `SubmitSolution` has rules on the
header_timestamp validity, and as far as I can tell they appear to be
compatible with the new timewarp fix rule [1]. Though it sounds each block
template software should be checked on its own here. With the same upgrade
occasion, it could be recommended that miners wall clock are synced with
NTP stratum 0 or stratum 1 devices, which would minimize attack surface
from timejacking issues already existent due to the 2 hours rule [2].
All that said, I think there are few minor downsides of instituting a new
Time inter-dependency between subsequent blocks. One is for mining
softwares you would have to ensure strict ordering of the template nTime
field for those 2 boundaries blocks in face of reorg or concurrent template
works on. A second one is a miner can move the MTP value as updated by the
next block, said block that miner might not mine itself, and as such the
consensus validity of time-based time-locked transactions.
Personally, I don't think those downsides raise a bottleneck to further
inquiry on this
cleaning up of the difficulty adjustement algorithm. Yet I think it would
be interesting
to ask if there are other consensus and mining software dependencies or
wall clocks hardening that we should consider in the context of a timewarp
fix.
Cheers,
Antoine (the other one)
ots hash: 612acbb8167f1a3e278524ce22846b35e466d4b9c51321e7b661d15973a13b3b
[0] https://github.com/ariard/bitcoin/tree/play-with-timewarp-fix-2
[1]
https://github.com/stratum-mining/sv2-spec/blob/main/07-Template-Distribution-Protocol.md
[2] https://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/e045e415-9f0b-4f90-9c65-3aeeecca785bn%40googlegroups.com.
------=_Part_323899_106706459.1724596602482
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi list,<br /><br />About fixing the timewarp attack, I think one aspect wa=
sn't mentioned in Pointsot's post<br />about consensus cleanup from few mon=
ths ago is potentially the necessity to have an upgrade of pool softwares. =
New consensus rule is the following "The nTime field of each block whose he=
ight, mod 2016, is 0 must be greater than or equal to the nTime field of th=
e immediately prior block minus 600".<br /><br />As it's noted in the clean=
up bip, if the last block of the period timestamp is in the<br />future, no=
n upgraded miners mining the first block of the period could see it orphane=
d<br />if the nTime field isn't adjusted accordingly. While this could aris=
e spontaneously from<br />unreliable local clocks, a malicious miner could =
deliberately exploit this new behavior by<br />offsetting last block nTime =
field to one hour in the future (consensus rule reminder: no<br />block mor=
e than 2 hours in the future), then next honest non-upgraded miner could na=
ively mine the first block of the next period which would be deemed invalid=
by new consensus rules. Malicious miner, aware of the nTime offsetting, ge=
ts an advantage to mine the first block of this period, which would be acce=
pted by all remaining network full-nodes. Assuming all network wall clocks =
are well in sync, there is little risk for a malicious miner to engage in s=
uch last block period nTime offsetting (scenario re-tested here [0]).<br />=
<br />New bitcoin core getblocktemplate code on testnet4 is adjusting the n=
Time field for<br />each first period block compared to the last block nTim=
e field minus 600s. However,<br />this upgrade behavior is far from being p=
orted in any other block template providers<br />(e.g getblocktemplate othe=
r implementations, stratum v2) in the mining ecosystem and<br />I don't kno=
w if it should be further documented or implemented (e.g addendum to bip23 =
?). E.g Stratum V2's `SubmitSolution` has rules on the header_timestamp val=
idity, and as far as I can tell they appear to be compatible with the new t=
imewarp fix rule [1]. Though it sounds each block template software should =
be checked on its own here. With the same upgrade occasion, it could be rec=
ommended that miners wall clock are synced with NTP stratum 0 or stratum 1 =
devices, which would minimize attack surface from timejacking issues alread=
y existent =C2=A0due to the 2 hours rule [2].<br /><br />All that said, I t=
hink there are few minor downsides of instituting a new Time inter-dependen=
cy between subsequent blocks. One is for mining softwares you would have to=
ensure strict ordering of the template nTime field for those 2 boundaries =
blocks in face of reorg or concurrent template works on. A second one is a =
miner can move the MTP value as updated by the next block, said block that =
miner might not mine itself, and as such the consensus validity of time-bas=
ed time-locked transactions.<br /><br />Personally, I don't think those dow=
nsides raise a bottleneck to further inquiry on this<br />cleaning up of th=
e difficulty adjustement algorithm. Yet I think it would be interesting<br =
/>to ask if there are other consensus and mining software dependencies or w=
all clocks hardening that we should consider in the context of a timewarp f=
ix.<br /><br />Cheers,<br />Antoine (the other one)<br />ots hash: 612acbb8=
167f1a3e278524ce22846b35e466d4b9c51321e7b661d15973a13b3b<br /><br />[0] htt=
ps://github.com/ariard/bitcoin/tree/play-with-timewarp-fix-2<br />[1] https=
://github.com/stratum-mining/sv2-spec/blob/main/07-Template-Distribution-Pr=
otocol.md<br />[2] https://culubas.blogspot.com/2011/05/timejacking-bitcoin=
_802.html<br />
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/e045e415-9f0b-4f90-9c65-3aeeecca785bn%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/e045e415-9f0b-4f90-9c65-3aeeecca785bn%40googlegroups.com</a>.=
<br />
------=_Part_323899_106706459.1724596602482--
------=_Part_323898_313843232.1724596602482--
|
