Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9E65BC002D for ; 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 ; 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 ; 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 ; Mon, 27 Jun 2022 12:03:51 +0000 (UTC) Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-318889e6a2cso82882357b3.1 for ; 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: In-Reply-To: From: Greg Sanders Date: Mon, 27 Jun 2022 08:03:38 -0400 Message-ID: To: Peter Todd , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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 "the mempool".=C2=A0



On Sun, Jun 26, 2022, 8:43 PM Peter Todd via bitcoin-= dev <bitcoin-dev@lists.linuxfoundation.org> wr= ote:
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 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.
>
> 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. >
> 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 co= injoin tx which never gets relayed: https://nitter.net/1440000bytes/status/1540727534093905920<= /a>

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<= 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
be detected and punished as well - they don't create a fundamentally ne= w
vulerability.

--
https://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.li= nuxfoundation.org/mailman/listinfo/bitcoin-dev
--00000000000087152e05e26cb6fe--