Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id AE461C002D for ; Fri, 8 Jul 2022 15:09:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 72F4B847E1 for ; Fri, 8 Jul 2022 15:09:46 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 72F4B847E1 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=WUullZQe 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 CrZAJK0QzDMX for ; Fri, 8 Jul 2022 15:09:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 83D5C847C2 Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by smtp1.osuosl.org (Postfix) with ESMTPS id 83D5C847C2 for ; Fri, 8 Jul 2022 15:09:45 +0000 (UTC) Received: by mail-pl1-x62d.google.com with SMTP id l12so11229145plk.13 for ; Fri, 08 Jul 2022 08:09:45 -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=kIa+U7nfY+B3X+/RsxgYaHpzdpHQWT8ShYGxS+IhT+4=; b=WUullZQeAYRDuEQ0kyVkI145FUPiFGAhe92TupVSn+KJbQKwG4NJbu0WbnIzii5KvY 1sMiTpSc653E6Qx6soLo8WT/PGd/eKpJTjBQ/EEyaYGYDQ5Dtvmsw+lclsVSPscS/x2z w7N21Kn9YtEte4PQhKWUbLwt2D+rlyyLu4f4i0wkGGsb5itzsYcEeP7shaWwmlhxOeza +SoV5rVyfhtE4Yv1xbf80bmydhb1zgG8ZXSOvY04QG47kce7a6bZNbTXaNy6ZSBIjie6 fHugFKdV4O+G9dgYdtavDhQtYCUFq1bcqRMYJ1nnbn0CpZtcntfA037fRHSIOGOuuEwe YnGQ== 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=kIa+U7nfY+B3X+/RsxgYaHpzdpHQWT8ShYGxS+IhT+4=; b=xWUFunt0sODSuaeJK+ZiLFGowISLOZFQBuy6+GSCe0FnEGeekn18YkNaZt/VYY2ruN TGKT3GCPNPuTlAWCgHFA5G082A+p2MhlGiGzLpoAXjnKara1KNTWZNWM/3URuy08i4Hv zWJZNd3qPxVY2R6GGvcxAdGCI0M+ZMTJ6tWV9o2om6pBNM6pIqH2I5JvbqhupUELIrV7 9I3lQ6C0l7Ty6Nm4nwZktXkpnZTB8RDiED2AKqF7NDFQ/VPplkLvN8w4jj8BVP06oIh0 ujgT6SGrb36ew7G0jF2ZuLMFHByZswgsqWSpNXxARZJYC9690qInZ71iyQXzjhhyPLWL h+6A== X-Gm-Message-State: AJIora+Q6FD4B3nNT0mFUUVzHHm1gGvL2IkIR1qiai7tgLV0S0AKsZXb IKHk6D8cB/wcJwr9BJwzCARiIgPMy/soEzcBsrI= X-Google-Smtp-Source: AGRyM1sPXLYKXJdE4PCMqRGUK6Y2gukI/tI9aMULQSGu1gcG6p/FFhmKuBejeSzEn+U/wMMF5+a/3sIDnYJOlvR2gVM= X-Received: by 2002:a17:902:8e85:b0:16a:380b:13a9 with SMTP id bg5-20020a1709028e8500b0016a380b13a9mr4247739plb.109.1657292984884; Fri, 08 Jul 2022 08:09:44 -0700 (PDT) MIME-Version: 1.0 References: <0ikzVrbv3tA2fyv4iW7b_gPJ-qkrJS3x9HzouSqLabK3yHthgigPt9YZhGlr4_nCutAlRREfFSw1JW0k5KhBgSj1aBI2MSDTLqYHGYbqNrg=@protonmail.com> In-Reply-To: From: Greg Sanders Date: Fri, 8 Jul 2022 11:09:33 -0400 Message-ID: To: Peter Todd , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000a723bd05e34c9734" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2022 15:09:46 -0000 --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
The attacker isn't guaranteed=C2=A0to 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.
<= div>
The other users' 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.

=C2=A0

On Fri, Jul 8, 2022 at 10:53 AM Pe= ter 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 partic= ipant 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 fundam= entally new
> > vulerability.
>
> 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.
>
> Inputs are already checked multiple times for double spend during coin= join round: https://github.com/zkSNACKs/WalletWasa= bi/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 us= ers?

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
more resources, because for a double-spend to be succesful, BTC has to be s= pent
on fees.

It's just a fact of life that a motivated attacker can DoS attack Wasab= i by
spending money. That's a design choice that's serving them well so = far.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000a723bd05e34c9734--