Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7977CC002D for ; 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 ; 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 ; 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 ; Sat, 9 Jul 2022 15:06:55 +0000 (UTC) Received: by mail-il1-x129.google.com with SMTP id a20so781651ilk.9 for ; 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: <0ikzVrbv3tA2fyv4iW7b_gPJ-qkrJS3x9HzouSqLabK3yHthgigPt9YZhGlr4_nCutAlRREfFSw1JW0k5KhBgSj1aBI2MSDTLqYHGYbqNrg=@protonmail.com> In-Reply-To: From: Antoine Riard Date: Sat, 9 Jul 2022 11:06:43 -0400 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="0000000000005de3de05e360ab90" X-Mailman-Approved-At: Sat, 09 Jul 2022 17:21:48 +0000 Cc: Bitcoin Protocol Discussion 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: 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 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
> 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.

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= .

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 attac= k Wasabi by
> spending money. That's a design choice that's s= erving them well so far.

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.

> The other users= ' only practical choice is to double-spend their own input
> to g= et their money back(at competitive rates much higher than the
> attac= ker), or wait and hope you win a propagation race somewhere.

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.

> 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.

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).

Antoine

Le=C2=A0ven. 8 juil. 2022 = =C3=A0=C2=A010:53, Peter Todd <pet= e@petertodd.org> a =C3=A9crit=C2=A0:
On Tue, Jul 05, 2022 at 08:46:51PM +0000, alice= xbt 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
--0000000000005de3de05e360ab90--