From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id B85F5C002D for ; Fri, 8 Jul 2022 19:44:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 7EE664014A for ; Fri, 8 Jul 2022 19:44:32 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 7EE664014A Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=SDAzR5VF X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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 7PU-9Apirs2M for ; Fri, 8 Jul 2022 19:44:30 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org D8B83400FD Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18]) by smtp2.osuosl.org (Postfix) with ESMTPS id D8B83400FD for ; Fri, 8 Jul 2022 19:44:29 +0000 (UTC) Date: Fri, 08 Jul 2022 19:44:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1657309467; x=1657568667; bh=8raF3yxmfonMc67FCMorGmgM/pG1eTsbauRDfndoTtY=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=SDAzR5VFl7kdgrLM5vePna5r0kS2Oc2qb2heSNeOJ2u5IrEqG3yq4tWUmngYGdWMa LioNrftYI7ploVFI7MBrvXPKqFeVICIvl/w0A3vIpfPfY+pcX7iqwKbh58SawuO6aL 6/8f3pOZmciapUrQX55lP/A8KSqExbK2SLIskBWFvgeosoFtX9/ccJSLB8masPly4/ LQBW00rZS8p0dVFar4OnF3zu9N4TYl2ndlJ5RcU4EGX8dCpQr1JDMkhwyXqoyS7Af/ VS7SjkLplMdsEd/RP5s3U/lOlEtYdrwSU8EnJCt+SgPtMGbpmVm3nw3aIZZV/8rcwZ g1QhS+bcX8XQg== To: Peter Todd From: alicexbt Reply-To: alicexbt Message-ID: In-Reply-To: References: <0ikzVrbv3tA2fyv4iW7b_gPJ-qkrJS3x9HzouSqLabK3yHthgigPt9YZhGlr4_nCutAlRREfFSw1JW0k5KhBgSj1aBI2MSDTLqYHGYbqNrg=@protonmail.com> Feedback-ID: 40602938:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 08 Jul 2022 22:39:30 +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: Fri, 08 Jul 2022 19:44:32 -0000 Hi Peter, > 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 requi= res > 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. There are 2 things: 1) Based on my understanding, round will not be aborted if a threshold is m= et for inputs and will continue irrespective of attacker trying different t= hings in the initial phases of round. I need to confirm this by testing alt= hough not feeling well today so it can take a few days. 2) Points mentioned by Greg Sanders are reasonable: There can be a differen= t 'mempool view' for coordinator, users and attacker. Attacker could use mi= nimum fee rate required for relay and this works differently when there is = enough demand for blockspace. 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 issu= e for governments or competitors that normally perform such attacks. The vulnerability reported is different from the things being discussed and= hopefully I will do a public disclosure this month. I observed some intere= sting things which I wanted to discuss. Full RBF pull request is already me= rged in bitcoin core and available in bitcoin knots if some users want to e= xperiment. /dev/fd0 Sent with Proton Mail secure email. ------- Original Message ------- On Friday, July 8th, 2022 at 2:53 PM, Peter Todd 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 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 f= uture > > > 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 th= is case will be difficult because the transaction is broadcasted after sign= ing and before coinjoin tx broadcast. > > > > Inputs are already checked multiple times for double spend during coinj= oin 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 use= rs? > > > 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 requi= res > 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