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 60668C002B for ; Fri, 10 Feb 2023 19:35:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 34C53414E6 for ; Fri, 10 Feb 2023 19:35:21 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 34C53414E6 Authentication-Results: smtp2.osuosl.org; dkim=pass (1024-bit key) header.d=woobling.org header.i=@woobling.org header.a=rsa-sha256 header.s=google header.b=l9Wsv6Fp 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 PaOD1UE7zYq2 for ; Fri, 10 Feb 2023 19:35:20 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 42FFE400CC Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) by smtp2.osuosl.org (Postfix) with ESMTPS id 42FFE400CC for ; Fri, 10 Feb 2023 19:35:20 +0000 (UTC) Received: by mail-lf1-x135.google.com with SMTP id bi36so9880487lfb.8 for ; Fri, 10 Feb 2023 11:35:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=woobling.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=crha9O7zyx3xmzdGYNZJU6bfaK0MJgkaUKIwmarHKts=; b=l9Wsv6FpngEuqvRZC4+133NCvoqv0HbQklmat4v1EmfVV+D9maDJ1ovKdVnYf/jeAk ob9JOSlO9PA5PNJAlZQZk7BgbvwdsO+DUAWyn2Bokr/kNjITfY2AZxVTgBAU/r8cAvZi 4qAtQuK7sZelG+xhXjNu+0MoXQ1qIcaMvPDPw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=crha9O7zyx3xmzdGYNZJU6bfaK0MJgkaUKIwmarHKts=; b=Uh/Y0FbxDKzk/QqxDPZEcPZVazgqDnV/4KokL8Rc7Af1ZfH781E8rVpRjMCXy3jEZM hPrBNWhNeRABSEdIQIfFyz23Uqo8se75OBeSUrMU1sTKT1LErBSEeC2cRMoLzZE2oiZu 4I4Lj2Sr1psRno+joJTSNRtKugbMgVFKLSz8NDYXON8dIcSPTcRkFT/kj7OoJZGgPnju SHUllRf+V44lko9j8BcaXA86+ttc0Ozxepaq4OmaBDR6XqYZHUIG1/FOGFuzDAqvxxnw w/q9aCKi7Q3bI5J/Ua39qMoA2kYNHE2F20Yh6xhsdr8sie4KYRO9YwynSqaUBs5lUX01 Gi2g== X-Gm-Message-State: AO0yUKUIdqLsnQthrvcOPD0w2MxS0VKY2mAwtzUyH2nAJu7BXHBg3LE4 fv8YJKr0TGK7hL+oOsajH3IhUxq57Ig6Olf0y3E1/g== X-Google-Smtp-Source: AK7set9Hc6ymaL3fpS4kZkbiwTr1HoR4lqqxNAeT+o8ZA2ILNLtlSmmei/Q+frE/fyWTqE1TUALKgghisZqYVdAWJ1M= X-Received: by 2002:ac2:44d9:0:b0:4d8:65c5:8685 with SMTP id d25-20020ac244d9000000b004d865c58685mr2253011lfm.244.1676057718021; Fri, 10 Feb 2023 11:35:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yuval Kogman Date: Fri, 10 Feb 2023 21:35:06 +0200 Message-ID: To: Antoine Riard Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Fri, 10 Feb 2023 19:37:12 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs 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, 10 Feb 2023 19:35:21 -0000 On Wed, 8 Feb 2023 at 02:56, Antoine Riard wrote: > From what I understand, there are many inputs for the coinjoin transaction, the latest signer provides an inflated witness downgrading the multi-party transaction feerate. Yep! > It doesn't sound to me a fee siphoning as occurring with loose malleability [0], rather another case of transaction-relay jamming where the adversary's goal is to slow down the confirmation of the transaction to waste everyone timevalue. > > I think the issue has already been mentioned to advocate updating Core's mempool acceptance policy, and allows wtxid-replacement [1]. There is also a description available here [2]. Yep, the mechanism is basically the same as witness malleability based jamming. Apologies for not citing, I think I must have seen that before but only remembered the pinning variants, and so did not recall it at the time that I wrote this up, which I did rather hastily. However, I do think the adversary model should be broadened, as there is a potential positive externality to a party which simply wishes to get some witness data confirmed in a block while paying less than the market rate, without needing to assume time sensitive contracts in the threat model. What I had in mind was the estimated witness size messages in the dual funding proposal and felt they would create a false sense of validation, specifically in the context of an adversary interested in having their ordinal inscriptions being paid for by someone else by subverting the a priori agreed upon feerate. From my point of view this is primarily an argument for RBF by default (ideally full RBF, as rule 3 of BIP 125 imposes difficult constraints on multiparty transaction construction) in such protocols. > I don't think increasing adversary costliness is that efficient as there is a scaling effect (e.g the feerate of the previous transaction can be used to feed N outputs for N dissociated attack contexts). Yes, that doesn't make things incentive compatible but allows the potential victims to have clearer bounds on the potential positive payoff to the adversary. I think that's mainly useful in conjunction constraining the order of signature submission, going from smallest to largest input seems intuitively compelling but it seems to me like ordering by feerate of creating transaction or perhaps some combination of the two might provide a stronger deterrent. Either way the main takeaway in my opinion is not that this is a serious attack, as it's hard to exploit in theory and as far as I know none of the currently deployed protocols are in any way vulnerable: 1. dual funding supports RBF and quite amenable to reputation based mitigations 2. in JoinMarket the taker can protect themselves 3. centralized coinjoins, despite misleading claims to the contrary by both vendors, currently strongly rely on a trusted server for many other aspects of the protocol and all three protocols are not currently exploitable as described (the attacker can't broadcast the transaction with a witness that would otherwise be rejected by the server) ... but rather that (full) RBF is required for incentive compatible multiparty transactions (or the closest approximation of incentive compatibility possible barring future soft forks).