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
|
Return-Path: <antoine.riard@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7977CC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 9 Jul 2022 15:06:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 5404C40179
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 9 Jul 2022 15:06:57 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 5404C40179
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=Ecqddp20
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
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 8fnOraDDP-o4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 9 Jul 2022 15:06:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org F320940114
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com
[IPv6:2607:f8b0:4864:20::129])
by smtp2.osuosl.org (Postfix) with ESMTPS id F320940114
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 9 Jul 2022 15:06:55 +0000 (UTC)
Received: by mail-il1-x129.google.com with SMTP id a20so781651ilk.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 09 Jul 2022 08:06:55 -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=t2GUPD2tGBof0Tn13M2JHTh50kIF40s+lrAWktHkiI4=;
b=Ecqddp20MWrUuFS0MWE4NY8B8pg7rVEjlm3wf+RxJBduOsAaQhn5qJt3s7m1YlnpA9
w4YMWoRiXj9qu3vkh5g2a4rQfcmWklYN5qMwAQ06J8DeIwNMk669RBRC0bluWJHQYe8f
V1GbybdiKDdz4PXyjVlv9+ROETB7WJdljLDfD8aEiiFaPsUFa4dmsk9nFTJ+PxtAZjbS
rT+9pqVeOraKTj6bV/rpNlPnbbQ4QABb02XNBF4+p4aXNxLfoDxZsUY7wZq7fHj2cFIy
3gaWr5W72578TzQXIsy3CU/v2QyEBYtYEanzKgPwUBpOBGk9G/+TLTZbgRh1bBURuXkr
aQJA==
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=t2GUPD2tGBof0Tn13M2JHTh50kIF40s+lrAWktHkiI4=;
b=VMeGpoCA/8O8lmQzpa7Q8oukJy10Q93U/e+wbD4b3jkE1VxCmDOwJqYW+1pk/JqXKD
aBCvFgyBuO/pjjSmg2BKk91M0D57JX6q9OGDUIE0bYoyy4rfRNwSTOMu4j0bxL7+Zgfv
Rt8hvLIkfDsF/EBg6u2MOj1ELlrmKrKKH/bZChskxstkiT+Q/CbtSAK6Zmx+aB8jeJo4
32m11EO0XK9vpIxhIiSsZ2U1FklsTvEgk4E7/WGDn445cdlPG3An6Ddmy0sgesP7eYID
2YJvstO7fGlogWGnSDMo2exrMsIiZKoTkK3D0iaBcoWdQi0fNSsjcVWqiJGEAO9iFP2z
dH8w==
X-Gm-Message-State: AJIora8IVNi+f4+Fv5NiQNH64HpTZZI+AapZyN60jsG/W3Ec18X8327t
F6Dzx7rzZmxlpMXCG1cJIBHykt870hBvCOA7hrc=
X-Google-Smtp-Source: AGRyM1v/IaEcot2sGxsfpeojGHJ/K9kurqDIozcu0ecf+1+FJ+sjR9RkvZrvb5tlW0Ys4VcigeVsFejeuNad7l/fbHs=
X-Received: by 2002:a05:6e02:1bcb:b0:2da:ab81:2f3e with SMTP id
x11-20020a056e021bcb00b002daab812f3emr5098655ilv.299.1657379214974; Sat, 09
Jul 2022 08:06:54 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GOh-7weEypT9JrzcwthZJqHOfj7sf9FMuqi5_FZv0g7w@mail.gmail.com>
<gmDNbfrrvaZL4akV2DFwCuKrls9SScQjqxeRoEorEiYlv24dPt1j583iOtcB2lFrxZc59N3kp7T9KIM4ycl4QOmGBfDOUmO-BVHsttvtvDc=@protonmail.com>
<CALZpt+FJ-R9yCoMLP=Vcxk1U7n=-LKHUGctFZj0K-vTMsz==ew@mail.gmail.com>
<RJEFmrnjbzKQCBr4L7ebwBLzg7QHGXlaE19zj6jfkxL6xjfodgbfssZBQSYxm783Y4X5awuhL9Gj8IaBc4npE2oh3d1xoudKTrSsJ-dk0VQ=@protonmail.com>
<CALZpt+HXB=xh3qtxJFM7yUzRu1uj-pPtLQmT=5QV0dNfVuTpfQ@mail.gmail.com>
<Pb8H4PbeS-RaNOKfekOPdY8gQo4_Syd3HoTK26AO872f7tCKyGnty56KtcvmvrXFOJdC7nQgNHoQ37M4MNXQ6vqQ9du6BFbvGLbY3BdYVpY=@protonmail.com>
<Yrj9N7k8osWsxhY4@petertodd.org>
<0ikzVrbv3tA2fyv4iW7b_gPJ-qkrJS3x9HzouSqLabK3yHthgigPt9YZhGlr4_nCutAlRREfFSw1JW0k5KhBgSj1aBI2MSDTLqYHGYbqNrg=@protonmail.com>
<YshE2QKBEVnbf+Bg@petertodd.org>
In-Reply-To: <YshE2QKBEVnbf+Bg@petertodd.org>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Sat, 9 Jul 2022 11:06:43 -0400
Message-ID: <CALZpt+H6H3M49O=-NduYd99VwSywGPoJPavKs8EDzdBi9pT5qg@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="0000000000005de3de05e360ab90"
X-Mailman-Approved-At: Sat, 09 Jul 2022 17:21:48 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s
security
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, 09 Jul 2022 15:06:57 -0000
--0000000000005de3de05e360ab90
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> Point is, the attacker is thousands of UTXOs can also DoS rounds by simpl=
y
> failing to complete the round. In fact, the double-spend DoS attack
requires
> more resources, because for a double-spend to be succesful, BTC has to be
spent
> on fees.
I think I agree that effectively a DoS-by-abstention is lower cost than a
DoS-by-RBF-otpout, as in the second case the UTXO double-spent must be
still acquired. However, I wonder if the second DoS case isn't more
economically efficient for the attacker as you can re-use the same UTXO (or
the lineage of it) many times as the coinjoin coordinator have a limited
visibility (in the very best case) of the network mempools to blame
confidently.
Acquiring thousands of UTXO, whatever the origin, isn't free. Electricity
burns if they have been mined, fiat if they have been acquired through
exchange, time and energy if they have been earned as income.
> It's just a fact of life that a motivated attacker can DoS attack Wasabi
by
> spending money. That's a design choice that's serving them well so far.
I believe it's hard to make any open, p2p coinjoin services robust against
a deep-pocketed attacker practicing that type of DoS attacks. In theory, an
attacker could maintain the DoS for long enough to ruin the reputation of
the service until it's out of the market. It would be interesting to know
if you can design a DoS mitigation (e.g against DoS-by-abstention) offering
the advantage to the targeted service after one-round or a fixed number of
rounds.
> The other users' only practical choice is to double-spend their own input
> to get their money back(at competitive rates much higher than the
> attacker), or wait and hope you win a propagation race somewhere.
Yes, that's of the annoying concern with DoS-by-RBF-optout against
DoS-by-abstention, while the latter can be mitigated without assuming a
on-chain cost for the participant, the former might be crafted such that
on-chain fees must be spent to sanitize the situation, worst in an
asymmetric way bounded by the max size of the coinjoin, I think.
> Double spend attack requires only one laptop and a few UTXOs. Even if
spent in some cases, would pay a few sats per transaction which won't be an
issue for governments or competitors that normally perform such attacks.
That's an interesting question. Interactive transaction construction
protocol being formalized by the BOLT process implied (hopefully) that
sooner or later multi-party coinjoin capabilities should be well supported
across the ecosystem. From that, we might seen a large-scale p2p market of
coinjoin (in the same way we have a HTLC routing market with LN), where a
participant can enter into them, without the high cost of installing
another wallet. I believe how do we mitigate all those classes of DoS to
avoid malicious coinjoin service providers to outlaw competitions that stay
open (reminder Minecraft and the Mirai Botnet story).
Antoine
Le ven. 8 juil. 2022 =C3=A0 10:53, Peter Todd <pete@petertodd.org> a =C3=A9=
crit :
> On Tue, Jul 05, 2022 at 08:46:51PM +0000, alicexbt wrote:
> > Hi Peter,
> >
> > > Note that Wasabi already has a DoS attack vector in that a participan=
t
> can stop
> > > participating after the first phase of the round, with the result tha=
t
> the
> > > coinjoin fails. Wasabi mitigates that by punishing participating in
> future
> > > rounds. Double-spends only create additional types of DoS attack that
> need to
> > > be detected and punished as well - they don't create a fundamentally
> new
> > > vulerability.
> >
> > I agree some DoS vectors are already mitigated however punishment in
> this case will be difficult because the transaction is broadcasted after
> signing and before coinjoin tx broadcast.
> >
> > Inputs are already checked multiple times for double spend during
> coinjoin round: https://github.com/zkSNACKs/WalletWasabi/pull/6460
> >
> > If all the inputs in the coinjoin transaction that failed to relay are
> checked and one or more are found to be spent later, what will be punishe=
d
> and how does this affect the attacker with thousands of UTXOs or normal
> users?
>
> Point is, the attacker is thousands of UTXOs can also DoS rounds by simpl=
y
> failing to complete the round. In fact, the double-spend DoS attack
> requires
> more resources, because for a double-spend to be succesful, BTC has to be
> spent
> on fees.
>
> It's just a fact of life that a motivated attacker can DoS attack Wasabi =
by
> spending money. That's a design choice that's serving them well so far.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--0000000000005de3de05e360ab90
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>> Point is, the attacker is thousands of UTXOs can=
also DoS rounds by simply<br>> failing to complete the round. In fact, =
the double-spend DoS attack requires<br>> more resources, because for a =
double-spend to be succesful, BTC has to be spent<br>> on fees.<br><br>I=
think I agree that effectively a DoS-by-abstention is lower cost than a=C2=
=A0 DoS-by-RBF-otpout, as in the second case the UTXO double-spent must be =
still acquired. However, I wonder if the second DoS case isn't more eco=
nomically efficient for the attacker as you can re-use the same UTXO (or th=
e lineage of it) many times as the coinjoin coordinator have a limited visi=
bility (in the very best case) of the network mempools to blame confidently=
.<br><br>Acquiring thousands of UTXO, whatever the origin, isn't free. =
Electricity burns if they have been mined, fiat if they have been acquired =
through exchange, time and energy if they have been earned as income.<br><b=
r>> It's just a fact of life that a motivated attacker can DoS attac=
k Wasabi by<br>> spending money. That's a design choice that's s=
erving them well so far.<br><br>I believe it's hard to make any open, p=
2p coinjoin services robust against a deep-pocketed attacker practicing tha=
t type of DoS attacks. In theory, an attacker could maintain the DoS for lo=
ng enough to ruin the reputation of the service until it's out of the m=
arket. It would be interesting to know if you can design a DoS mitigation (=
e.g against DoS-by-abstention) offering the advantage to the targeted servi=
ce after one-round or a fixed number of rounds.<br><br>> The other users=
' only practical choice is to double-spend their own input<br>> to g=
et their money back(at competitive rates much higher than the<br>> attac=
ker), or wait and hope you win a propagation race somewhere.<br><br>Yes, th=
at's of the annoying concern with DoS-by-RBF-optout against DoS-by-abst=
ention, while the latter can be mitigated without assuming a on-chain cost =
for the participant, the former might be crafted such that on-chain fees mu=
st be spent to sanitize the situation, worst in an asymmetric way bounded b=
y the max size of the coinjoin, I think.<br><br>> Double spend attack re=
quires only one laptop and a few UTXOs. Even if spent in some cases, would =
pay a few sats per transaction which won't be an issue for governments =
or competitors that normally perform such attacks.<br><br>That's an int=
eresting question. Interactive transaction construction protocol being form=
alized by the BOLT process implied (hopefully) that sooner or later multi-p=
arty coinjoin capabilities should be well supported across the ecosystem. F=
rom that, we might seen a large-scale p2p market of coinjoin (in the same w=
ay we have a HTLC routing market with LN), where a participant can enter in=
to them, without the high cost of installing another wallet. I believe how =
do we mitigate all those classes of DoS to avoid malicious coinjoin service=
providers to outlaw competitions that stay open (reminder Minecraft and th=
e Mirai Botnet story).<br><br></div>Antoine<br></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 8 juil. 2022 =
=C3=A0=C2=A010:53, Peter Todd <<a href=3D"mailto:pete@petertodd.org">pet=
e@petertodd.org</a>> a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">On Tue, Jul 05, 2022 at 08:46:51PM +0000, alice=
xbt wrote:<br>
> Hi Peter,<br>
> <br>
> > Note that Wasabi already has a DoS attack vector in that a partic=
ipant can stop<br>
> > participating after the first phase of the round, with the result=
that the<br>
> > coinjoin fails. Wasabi mitigates that by punishing participating =
in future<br>
> > rounds. Double-spends only create additional types of DoS attack =
that need to<br>
> > be detected and punished as well - they don't create a fundam=
entally new<br>
> > vulerability.<br>
> <br>
> I agree some DoS vectors are already mitigated however punishment in t=
his case will be difficult because the transaction is broadcasted after sig=
ning and before coinjoin tx broadcast.<br>
> <br>
> Inputs are already checked multiple times for double spend during coin=
join round: <a href=3D"https://github.com/zkSNACKs/WalletWasabi/pull/6460" =
rel=3D"noreferrer" target=3D"_blank">https://github.com/zkSNACKs/WalletWasa=
bi/pull/6460</a><br>
> <br>
> If all the inputs in the coinjoin transaction that failed to relay are=
checked and one or more are found to be spent later, what will be punished=
and how does this affect the attacker with thousands of UTXOs or normal us=
ers?<br>
<br>
Point is, the attacker is thousands of UTXOs can also DoS rounds by simply<=
br>
failing to complete the round. In fact, the double-spend DoS attack require=
s<br>
more resources, because for a double-spend to be succesful, BTC has to be s=
pent<br>
on fees.<br>
<br>
It's just a fact of life that a motivated attacker can DoS attack Wasab=
i by<br>
spending money. That's a design choice that's serving them well so =
far.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"=
rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div>
--0000000000005de3de05e360ab90--
|