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
|
Delivery-date: Tue, 11 Feb 2025 16:06:00 -0800
Received: from mail-yb1-f187.google.com ([209.85.219.187])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBC3PT7FYWAMRBXWLV66QMGQEVMB5SXA@googlegroups.com>)
id 1ti0GN-0002yT-D4
for bitcoindev@gnusha.org; Tue, 11 Feb 2025 16:06:00 -0800
Received: by mail-yb1-f187.google.com with SMTP id 3f1490d57ef6-e54da6701d2sf9386865276.0
for <bitcoindev@gnusha.org>; Tue, 11 Feb 2025 16:05:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1739318753; x=1739923553; 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:references:in-reply-to:message-id:to:from:date:sender:from
:to:cc:subject:date:message-id:reply-to;
bh=1HSlJipyOPWy+Ch4jqROw1EAJQ+uI7SVRQ4dr83xO3Y=;
b=p5FwEZbmF+d+PTaqd8qw5Jec/vdLOGY5pjMqxtgaJfS7Pb3OqNj5K0Lz7x54YJkhOO
SHJjI6Q0a/JiIPee/vCBuglin26HNFVK6MllzWnaT5Boy6vujdGgm1uP3MLNiRpd2nK6
xOaoOd1iMW0zMSVfXdr+FqRg6y8m2lWDt5eQuKVBbe2TyuFSnLanVjN0qRdbKg2KpVcI
fzl53aTDak61iRiVQqTLc+ZEfe6gE68ZE0uEHwt46n/M9Yarg404pLqwnyRr/AG83Vrh
pxzJEFNn9wV4Zufpuiz4HWld6Lo/wZ4/adfeJbQpOorrOAfCQG/mq7feDSH1HiESPYwo
M0FQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1739318753; x=1739923553; 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:references:in-reply-to:message-id:to:from:date:from:to:cc
:subject:date:message-id:reply-to;
bh=1HSlJipyOPWy+Ch4jqROw1EAJQ+uI7SVRQ4dr83xO3Y=;
b=UaB8tKNmO4EOnGYXDVzm7NgJEPCpags4ifnDKv70D/RlrEyGODUBTbezMG5T7xBXUK
i63UJtR5sC+BJOzcBKsvnlnTF/FgWWEsW80VXJlms2LvwmLepsP9q1PFcQEW6Al8hz3I
3wosbQUw9oMbhEfbsUF02SCD/l39c/RORgD6n+F2l/Q8j+ahPORQqhL9VjP9uNFuev4S
o8ix4rxbY/I/p/n0loXrGVOM4c4P3QujqrwvFpJDEzN4qih49xQLrai/iL4fLCiNGyAy
7Q5zInuboqgDt5XqYKNR9J372blofUM0BYJqvweRfF5Lj/a42dF47qukIdjygLoQgV7X
m5zw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1739318753; x=1739923553;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=1HSlJipyOPWy+Ch4jqROw1EAJQ+uI7SVRQ4dr83xO3Y=;
b=q7o3pY2YreVsTECJMKoLvEjH3PRbvEmYM2fltBnz44rAxeCmadNZLJqS1wfAnyZDkE
f6uvitwKLHhq1F/s923ueDzVv4Oi+fG4ZpKHYwQUlBOKNlZznWttmc4vGGGjG1VGJuaE
nqaYmmcnvbANj2U++ZpJGVnf4SlhII8FQ/CyNtlIDI6SuLYgiJY0aZwFo5cfGRiS9yr0
TYwmN574OAK6aHe8vZgGXk1Nts7kE1A/+dlxDqi++PJ9P/VGxC+BGaJTA+uiSZU3B1Km
R6T4pVS27Iv6D6eUOX+2anS4qhupl4vsfKwv4OvEBc5/sqQG0HJM9LWlt/QVZ/CU8tke
XU/A==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXgwBwlICcA9ReD5SFupFbFtp7koMvjbPi5lHGr1BQn1S0z/IDepSI6A39Z4E/KyIAGi4CPFEnbOfKI@gnusha.org
X-Gm-Message-State: AOJu0YxOOIglakeIIrXOatoSY3pYlYla+e6mtDg3VMvlZH84eEeY4Dy1
ZNeio4PbRgNz8tJt6REUqQ4jQ+kNQmyRpRnRYtWX+dwNTkt/assi
X-Google-Smtp-Source: AGHT+IF/rgM5btrl3GRC99CX4WFOwHZdlCPZG2b5mUrF6mO5FOZFjIFb2bUW4zVbzSoKftykpmVBTA==
X-Received: by 2002:a05:6902:2382:b0:e5b:3a7b:1221 with SMTP id 3f1490d57ef6-e5d9f0fcadcmr1304372276.14.1739318753386;
Tue, 11 Feb 2025 16:05:53 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:abab:0:b0:e5b:3adb:a133 with SMTP id 3f1490d57ef6-e5b46087878ls290736276.1.-pod-prod-03-us;
Tue, 11 Feb 2025 16:05:49 -0800 (PST)
X-Received: by 2002:a05:690c:30c:b0:6f9:a90a:f7f2 with SMTP id 00721157ae682-6fb1f6c42a8mr17054047b3.34.1739318749688;
Tue, 11 Feb 2025 16:05:49 -0800 (PST)
Received: by 2002:a05:690c:4448:b0:6f9:a930:a709 with SMTP id 00721157ae682-6f9b1de8b9ams7b3;
Tue, 11 Feb 2025 13:20:11 -0800 (PST)
X-Received: by 2002:a05:690c:3687:b0:6f9:50ed:e6eb with SMTP id 00721157ae682-6fb1f27c541mr13924927b3.27.1739308810637;
Tue, 11 Feb 2025 13:20:10 -0800 (PST)
Date: Tue, 11 Feb 2025 13:20:10 -0800 (PST)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <87360fbe-30dd-4e18-acbf-7416c47ebc61n@googlegroups.com>
In-Reply-To: <CAGL6+mFYCKjhD8O1G9diC4pbM=_XubW0YxTfeqyyRpDe9t2fng@mail.gmail.com>
References: <jiyMlvTX8BnG71f75SqChQZxyhZDQ65kldcugeIDJVJsvK4hadCO3GT46xFc7_cUlWdmOCG0B_WIz0HAO5ZugqYTuX5qxnNLRBn3MopuATI=@protonmail.com>
<CAGL6+mFYCKjhD8O1G9diC4pbM=_XubW0YxTfeqyyRpDe9t2fng@mail.gmail.com>
Subject: Re: [bitcoindev] Update on the Great Consensus Cleanup Revival
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_331308_116972442.1739308810117"
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_331308_116972442.1739308810117
Content-Type: multipart/alternative;
boundary="----=_Part_331309_1883248253.1739308810117"
------=_Part_331309_1883248253.1739308810117
Content-Type: text/plain; charset="UTF-8"
Hi Darosior,
> I believe it is important to bundle all fixes together to make up for the
substantial fixed cost of deploying a soft fork. It also seems absurd to
deploy a soft fork aimed at patching security bugs, but only fix some of
them and lea> ve the protocol partly vulnerable. While it is technically
possible it is not something i want to encourage.
I don't wish to be dogmatic here, though I believe we have 2 distinct
things. There is (a) to have 4 distinct BIPs for each fix
("timewarp"/"worst-block-time"/"merkle-tree-weakness"/"enhanced-duplicated-txn")
and there is (b) to bundle all the fixes together as of course there is
substantial ecosystem coordination cost to deploy a soft fork, even with
BIP9. Getting 4 distinct BIPs, it's of course a bit more work for the soft
fork authors and champions, though I think this avoid too-beefy
ill-written BIP as we already had and undocumented future rules in the
script interpreter code like the SIGPUSHONLY check I was pointing out.
Apart of this editorial good practice motivation, this also indeed make it
simpler to deploy the fix one by one (of course you can always hack-in
activation code, even if it's single BIP), in the pessimistic scenario in
the future there are no consensus on all the fixes, though only a subset of
the 4 ones. In that optic, yes if we can get in 3 of the 4 fixes in a
bundled soft fork and the remaining one at a latter time, it would be
already a win to reduce the protocol vulnerability exposure.
It's unlike the Taproot patchset here, each proposed soft-fork fix is
supposed to be addressing a vulnerability of its own, and there is almost
no technical coupling between them (well one could go to argue there is one
among the timewarp fix and the worst-block-validation time, if you go to
consider the maximum DoS surface of a full-node under wall clock time). I
don't think it's a question of wishing what we wished to encourage as the
"ideal" deployment of this set of consensus rules changes, as if there are
good technical reasons to object on 1 fix and no consensus, this shouldn't
prevent to be realistic and go to deploy all the remaining ones for which
there is consensus.
> Regarding the confiscation surface, please note the specific concerns
raised about the 2019 proposal do not apply to the fix proposed here. The
new approach to mitigating the worst case validation time is extremely
conservative in this regard: no opcodes or other Script functionality get
disabled. Only a limit is introduced at the transaction level, which allows
to pinpoint exactly the harmful behaviour without rendering any innocent
transaction invalid.
I'm not sure if there is already code, and even a BIP on the
"worst-block-validation-time", though it's unclear to me if the limit aims
to apply on UTXO spends spending lecacy scripts ex post to the activation
(as I think the proposal of few months ago was laying out) or ex ante to
the activation. If the latter one, with a "retro-active" confiscation
surface, I think it's akin to the specific concerns raised in 2019, and if
it's something like that we should be
very careful in the design.
> As one would expect due to the larger design space available to fix this
issue, this private thread is where most of the discussion would happen.
There is another point - I'm sharing the practice on not exposing all
experimentation on the worst-block-validation-time, as you never know it's
the wild Internet and there can be always script kiddies at the corner of
the block for unpatched vulnerabilities. On the other hand, we're proposing
to change what is the "consensus" definition of people money, so a bit more
of publicity in rationalizing why the changes are proposed could be
welcome. For clarity I have access on the thread and there is bunch of
other devs. It's always a (hard) question how much info you share on
vulnerabilities in the process of fixing them.
Anyway, I'll go to review code+BIP(s) for all the fixes, those raised
points are just relevant to keep in mind imho.
Best,
Antoine R. (nah you're evil, i'm evil, we're all evil, btc is beyond good
and evil)
OTS hash: 0334fb9d557426c4f7d71d3e99bb9badbfd87903
--
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 visit https://groups.google.com/d/msgid/bitcoindev/87360fbe-30dd-4e18-acbf-7416c47ebc61n%40googlegroups.com.
------=_Part_331309_1883248253.1739308810117
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Darosior,<br /><br />> I believe it is important to bundle all fixes =
together to make up for the substantial fixed cost of deploying a soft fork=
. It also seems absurd to deploy a soft fork aimed at patching security bug=
s, but only fix some of them and lea> ve the protocol partly vulnerable.=
While it is technically possible it is not something i want to encourage.<=
br /><br />I don't wish to be dogmatic here, though I believe we have 2 dis=
tinct things. There is (a) to have 4 distinct BIPs for each fix ("timewarp"=
/"worst-block-time"/"merkle-tree-weakness"/"enhanced-duplicated-txn") and t=
here is (b) to bundle all the fixes together as of course there is substant=
ial ecosystem coordination cost to deploy a soft fork, even with BIP9. Gett=
ing 4 distinct BIPs, it's of course a bit more work for the soft fork autho=
rs and champions, =C2=A0though I think this avoid too-beefy ill-written BIP=
as we already had and undocumented future rules in the script interpreter =
code like the SIGPUSHONLY check I was pointing out.<br /><br />Apart of thi=
s editorial good practice motivation, this also indeed make it simpler to d=
eploy the fix one by one (of course you can always hack-in activation code,=
even if it's single BIP), in the pessimistic scenario in the future there =
are no consensus on all the fixes, though only a subset of the 4 ones. In t=
hat optic, yes if we can get in 3 of the 4 fixes in a bundled soft fork and=
the remaining one at a latter time, it would be already a win to reduce th=
e protocol vulnerability exposure.<br /><br />It's unlike the Taproot patch=
set here, each proposed soft-fork fix is supposed to be addressing a vulner=
ability of its own, and there is almost no technical coupling between them =
(well one could go to argue there is one among the timewarp fix and the wor=
st-block-validation time, if you go to consider the maximum DoS surface of =
a full-node under wall clock time). I don't think it's a question of wishin=
g what we wished to encourage as the "ideal" deployment of this set of cons=
ensus rules changes, as if there are good technical reasons to object on 1 =
fix and no consensus, this shouldn't prevent to be realistic and go to depl=
oy all the remaining ones for which there is consensus.<br /><br />> Reg=
arding the confiscation surface, please note the specific concerns raised a=
bout the 2019 proposal do not apply to the fix proposed here. The new appro=
ach to mitigating the worst case validation time is extremely conservative =
in this regard: no opcodes or other Script functionality get disabled. Only=
a limit is introduced at the transaction level, which allows to pinpoint e=
xactly the harmful behaviour without rendering any innocent transaction inv=
alid.<br /><br />I'm not sure if there is already code, and even a BIP on t=
he "worst-block-validation-time", though it's unclear to me if the limit ai=
ms to apply on UTXO spends spending lecacy scripts ex post to the activatio=
n (as I think the proposal of few months ago was laying out) or ex ante to =
the activation. If the latter one, with a "retro-active" confiscation surfa=
ce, I think it's akin to the specific concerns raised in 2019, and if it's =
something like that we should be<br />very careful in the design.<br /><br =
/>> As one would expect due to the larger design space available to fix =
this issue, this private thread is where most of the discussion would happe=
n. <br /><br />There is another point - I'm sharing the practice on not exp=
osing all experimentation on the worst-block-validation-time, as you never =
know it's the wild Internet and there can be always script kiddies at the c=
orner of the block for unpatched vulnerabilities. On the other hand, we're =
proposing to change what is the "consensus" definition of people money, so =
a bit more of publicity in rationalizing why the changes are proposed could=
be welcome. For clarity I have access on the thread and there is bunch of =
other devs. It's always a (hard) question how much info you share on vulner=
abilities in the process of fixing them.<br /><br />Anyway, I'll go to revi=
ew code+BIP(s) for all the fixes, those raised points are just relevant to =
keep in mind imho.<br /><br />Best,<br />Antoine R. (nah you're evil, i'm e=
vil, we're all evil, btc is beyond good and evil)<br />OTS hash: 0334fb9d55=
7426c4f7d71d3e99bb9badbfd87903<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 visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/87360fbe-30dd-4e18-acbf-7416c47ebc61n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/87360fbe-30dd-4e18-acbf-7416c47ebc61n%40googlegroups.com</a>.<br />
------=_Part_331309_1883248253.1739308810117--
------=_Part_331308_116972442.1739308810117--
|
