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: Greg Sanders <gsanders87@gmail.com>
Date: Fri, 8 Jul 2022 11:09:33 -0400
Message-ID: <CAB3F3DtCuEBXo9r+UoS2z8npvVeR0hU-R7ZHcngPNdE6Jr+Zgw@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a723bd05e34c9734"
Subject: Re: [bitcoin-dev] Playing with full-rbf peers for fun and L2s
	security
Precedence: list

--000000000000a723bd05e34c9734
Content-Type: text/plain; charset="UTF-8"

The attacker isn't guaranteed to spend *any* funds to disrupt the protocol
indefinitely, that's the issue here. In this scenario, her input double
spend is at an impractical feerate, and is never included in a block,
sitting at the bottom of the mempool.

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.


On Fri, Jul 8, 2022 at 10:53 AM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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 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.
> >
> > 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 punished
> 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 simply
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>The attacker isn&#39;t guaranteed=C2=A0to spend *any*=
 funds to disrupt the protocol indefinitely, that&#39;s the issue here. In =
this scenario, her input double spend is at an impractical feerate, and is =
never included in a block, sitting at the bottom of the mempool.<br></div><=
div><br></div><div>The other users&#39; only practical choice is to double-=
spend their own input to get their money back(at competitive rates much hig=
her than the attacker), or wait and hope you win a propagation race somewhe=
re.</div><div><br></div><div>=C2=A0</div></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jul 8, 2022 at 10:53 AM Pe=
ter Todd via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Jul 05, 2022 at 08:=
46:51PM +0000, alicexbt 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>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000a723bd05e34c9734--