path: root/fd/c56f200af7fc7097c3f30ac6cc801b0a204c7c

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>&gt; Point is, the attacker is thousands of UTXOs can=
 also DoS rounds by simply<br>&gt; failing to complete the round. In fact, =
the double-spend DoS attack requires<br>&gt; more resources, because for a =
double-spend to be succesful, BTC has to be spent<br>&gt; 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&#39;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&#39;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>&gt; It&#39;s just a fact of life that a motivated attacker can DoS attac=
k Wasabi by<br>&gt; spending money. That&#39;s a design choice that&#39;s s=
erving them well so far.<br><br>I believe it&#39;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&#39;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>&gt; The other users=
&#39; only practical choice is to double-spend their own input<br>&gt; to g=
et their money back(at competitive rates much higher than the<br>&gt; attac=
ker), or wait and hope you win a propagation race somewhere.<br><br>Yes, th=
at&#39;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>&gt; 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&#39;t be an issue for governments =
or competitors that normally perform such attacks.<br><br>That&#39;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 &lt;<a href=3D"mailto:pete@petertodd.org">pet=
e@petertodd.org</a>&gt; 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>
&gt; Hi Peter,<br>
&gt; <br>
&gt; &gt; Note that Wasabi already has a DoS attack vector in that a partic=
ipant can stop<br>
&gt; &gt; participating after the first phase of the round, with the result=
 that the<br>
&gt; &gt; coinjoin fails. Wasabi mitigates that by punishing participating =
in future<br>
&gt; &gt; rounds. Double-spends only create additional types of DoS attack =
that need to<br>
&gt; &gt; be detected and punished as well - they don&#39;t create a fundam=
entally new<br>
&gt; &gt; vulerability.<br>
&gt; <br>
&gt; 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>
&gt; <br>
&gt; 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>
&gt; <br>
&gt; 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&#39;s just a fact of life that a motivated attacker can DoS attack Wasab=
i by<br>
spending money. That&#39;s a design choice that&#39;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> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div>

--0000000000005de3de05e360ab90--