path: root/36/6982bfb0a7f8a35805c26bea8a0dc76bd18ba8

Return-Path: <gsanders87@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9E65BC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 27 Jun 2022 12:03:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 7958C82897
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 27 Jun 2022 12:03:53 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 7958C82897
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=YM+W9EaV
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id WRUCRVHy9fMB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 27 Jun 2022 12:03:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 52E4B82893
Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com
 [IPv6:2607:f8b0:4864:20::1134])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 52E4B82893
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 27 Jun 2022 12:03:51 +0000 (UTC)
Received: by mail-yw1-x1134.google.com with SMTP id
 00721157ae682-318889e6a2cso82882357b3.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 27 Jun 2022 05:03:51 -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=vzJ3OthDUh/oKtdkbvGGTCYYksP9QDDG05nbIQcgOUI=;
 b=YM+W9EaVXJSjs4Vnvz7rx9zMPB3hL6degSmXlQriKXlGAbcj3rs3aAFx9qFI3tTzmH
 vwW5pPz1wC9gw2pbME2NUDeybBsIkGwwfMd5agrkVetjDTjIYs6PS5kUdMltzmhbTFkN
 inmU/kOi3duVGYw7IdSq52vhE8tqgrdUhJaRP7CEjzGQ6rmCdXjKyPbF+kitLtrM3hEx
 XvtBNAWHOB0741ebF6R+NCgGvGuWF+PSVeMNViASgO4nUdT2Cmb4IIvYSUNrhMbdhXfC
 sHc5/91IHDZjd81Y95biSGv462t5gdwplnrcNtDqmXNQMhtii7rKp7GSNujXt6qx7WC1
 /dRA==
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=vzJ3OthDUh/oKtdkbvGGTCYYksP9QDDG05nbIQcgOUI=;
 b=JrNaZcxuLOk9LKG7XdEJZyICzKdSXYHCsLb8vG3Xd+q5n+nwjh1ouQpNIi03KD3Hzd
 h63sY8D9NZMkzsDzPUOfbtll/IuL2uGW+M3UHow9KhuK9fTNHiB8driMcQihV7dCP82y
 zJQquXDPTu0Od59V8R07ev9gi3cetKF9jNSGjrXqs69Lf9ZGKPRybbBl+2dnbV28KEEh
 g53zHg1sqfxSw5qffJDyWHW8bmKJ3uCG121B9BKOIYLAFVRptPSBiYBBNGV7NLwhdd+s
 5g4/1VtxNGsvOSqgfDWIu3OBlw30QqOVWkwIJRuT34IaRNk3CUqKlmYWvtRStpLE+WYC
 GS4w==
X-Gm-Message-State: AJIora/EFG6koOnrBTtNxJ12gPX5vfFdcpYO0poWhQyCSIkKIQ9MZzi2
 uJvzACX8ZI0yEBbiqJSiNngdowTt9uohk0R0x84c9PYj
X-Google-Smtp-Source: AGRyM1tA3fqj23zs2RUYKl/6LZMhb5LHdUrwkYIipVFZjIPpz+pVt5q6TJFtlUw1svWiMHWUPElJ/qtFJpLd42I0MWE=
X-Received: by 2002:a81:1397:0:b0:317:86c9:4472 with SMTP id
 145-20020a811397000000b0031786c94472mr14902123ywt.466.1656331430203; Mon, 27
 Jun 2022 05:03:50 -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>
In-Reply-To: <Yrj9N7k8osWsxhY4@petertodd.org>
From: Greg Sanders <gsanders87@gmail.com>
Date: Mon, 27 Jun 2022 08:03:38 -0400
Message-ID: <CAB3F3DtwX=nkcYPDHxFygEMZafhD3m+XuKc+BKuhwFs0J4VNUA@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000087152e05e26cb6fe"
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: Mon, 27 Jun 2022 12:03:53 -0000

--00000000000087152e05e26cb6fe
Content-Type: text/plain; charset="UTF-8"

One key difference seems to be that properly punishing someone based on
mempool behavior seems much more difficult. As we all know there is no "the
mempool".



On Sun, Jun 26, 2022, 8:43 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sun, Jun 26, 2022 at 04:40:24PM +0000, alicexbt via bitcoin-dev wrote:
> > Hi Antoine,
> >
> > Thanks for sharing the DoS attack example with alternatives.
> >
> > > - Caroll broadcasts a double-spend of her own input C, the
> double-spend is attached with a low-fee (1sat/vb) and it does _not_ signal
> opt-in RBF
> > > - Alice broadcasts the multi-party transaction, it is rejected by the
> network mempools because Alice double-spend is already present
> >
> > I think this affects almost all types of coinjoin transaction including
> coordinator based implementations. I tried a few things and have already
> reported details for an example DoS attack to one of the team but there is
> no response yet.
> >
> > It was fun playing with RBF, DoS and Coinjoin. Affected projects should
> share their opinion about full-rbf as it seems it might improve things.
> >
> > Example:
> >
> > In Wasabi an attacker can broadcast a transaction spending input used in
> coinjoin after sending signature in the round. This would result in a
> coinjoin tx which never gets relayed:
> https://nitter.net/1440000bytes/status/1540727534093905920
>
> Note that Wasabi already has a DoS attack vector in that a participant can
> stop
> participating after the first phase of the round, with the result that 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.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--00000000000087152e05e26cb6fe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">One key difference seems to be that properly punishing so=
meone based on mempool behavior seems much more difficult. As we all know t=
here is no &quot;the mempool&quot;.=C2=A0<div dir=3D"auto"><br></div><div d=
ir=3D"auto"><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Sun, Jun 26, 2022, 8:43 PM Peter Todd via bitcoin-=
dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"=
_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">On Sun, Jun 26, 2022 at 04:40:=
24PM +0000, alicexbt via bitcoin-dev wrote:<br>
&gt; Hi Antoine,<br>
&gt; <br>
&gt; Thanks for sharing the DoS attack example with alternatives.<br>
&gt; <br>
&gt; &gt; - Caroll broadcasts a double-spend of her own input C, the double=
-spend is attached with a low-fee (1sat/vb) and it does _not_ signal opt-in=
 RBF<br>
&gt; &gt; - Alice broadcasts the multi-party transaction, it is rejected by=
 the network mempools because Alice double-spend is already present<br>
&gt; <br>
&gt; I think this affects almost all types of coinjoin transaction includin=
g coordinator based implementations. I tried a few things and have already =
reported details for an example DoS attack to one of the team but there is =
no response yet.<br>
&gt; <br>
&gt; It was fun playing with RBF, DoS and Coinjoin. Affected projects shoul=
d share their opinion about full-rbf as it seems it might improve things.<b=
r>
&gt; <br>
&gt; Example:<br>
&gt; <br>
&gt; In Wasabi an attacker can broadcast a transaction spending input used =
in coinjoin after sending signature in the round. This would result in a co=
injoin tx which never gets relayed: <a href=3D"https://nitter.net/1440000by=
tes/status/1540727534093905920" rel=3D"noreferrer noreferrer noreferrer" ta=
rget=3D"_blank">https://nitter.net/1440000bytes/status/1540727534093905920<=
/a><br>
<br>
Note that Wasabi already has a DoS attack vector in that a participant 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&#39;t create a fundamentally ne=
w<br>
vulerability.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer noreferrer noreferrer" =
target=3D"_blank">https://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D=
"http://petertodd.org" rel=3D"noreferrer noreferrer noreferrer" target=3D"_=
blank">petertodd.org</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000087152e05e26cb6fe--