From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 26A76C000B for ; Tue, 22 Mar 2022 19:05:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 12D6F6129D for ; Tue, 22 Mar 2022 19:05:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UdamONY9LfMN for ; Tue, 22 Mar 2022 19:05:05 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) by smtp3.osuosl.org (Postfix) with ESMTPS id 1446A612C3 for ; Tue, 22 Mar 2022 19:05:04 +0000 (UTC) Received: by mail-pl1-x62f.google.com with SMTP id x2so2760395plm.7 for ; Tue, 22 Mar 2022 12:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=N/LsP5kf36GdCCJC5MGMF5FkEweo+KOabPbNZ5S+oCU=; b=TJReOmq1rPYws8PfPUPzI95IaoOKc4Bv1kVwo/N2isAyE0SZcCuX2u+hUGVC2aBbRS jtRwxdYu5rX3uv/33tnArlVslbfRd0o002pQHsDz7VSKttI7qn0EqpcyTXLpP/uVkaYA w3m/z3pWpqxQSphs4jy5m8QmLK9dSr9xzUsZi9owcaG7GIqyC4CGew6+J1eoYDSD0OUp a0o5B9raxo6P5fSrBh5if1Kgh+eib1dZ92cBshEBH/oui4QUEjT408cBv7pyMx1wySDo zUm0Wym2L1nY52ItPO8k0o25W6qnLNwmjWOxSlkrFO5XRElBvB5o6/Y4TRv8heZm0BGl zZQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=N/LsP5kf36GdCCJC5MGMF5FkEweo+KOabPbNZ5S+oCU=; b=N4Aop+mjTfL2DANBlW6n/3MJB9/6hBIToYbf/X6Rjmgzb+Lwkyq8etw+7NaMr/O+UN NOV7KZUDaEHPNCy65wsrDf4Uuv0gZQFL9czyTA2mAm/CGsCt3hPTNSljvgLVpVoJQynL XmT7+S0JI44EG4KM2bkFtEZE0bnjfyShBTEKekgR2ofO9M8Vs5nlL7qEyZXrRuS8MidP W0zhlMaiOKZPhPIPridIBcipL4xkinLBD0n7rsY7WVFdcHaQzNMTdeSebyOIHCvBSekT nhLnpCLIdQfQ6FvV3KNSNjs/9eJht3VN9l2jxnyDHZke5ILTf4QE0VMmsTJ/yZHbqEw/ Q0Bw== X-Gm-Message-State: AOAM532n7/m+xNAp0wIyik+8gKpeStu1sUmhxoHDb2+2aHa0UWxozXXa ut6yI8nbKg9JkCRdFQXSCRFXR9/CYaihcrb5UZzG2dtEaq4= X-Google-Smtp-Source: ABdhPJwS64EB3Mze43Hqrp/qqVy5GlPMq/kGhqSi1rznXQgBPucUG62Oe5L3hR2lPBxQ7kLd4ptUQ/xhH6IYmhs5N1o= X-Received: by 2002:a17:90a:17ab:b0:1bf:9519:fe86 with SMTP id q40-20020a17090a17ab00b001bf9519fe86mr6840344pja.25.1647975903087; Tue, 22 Mar 2022 12:05:03 -0700 (PDT) MIME-Version: 1.0 From: Larry Ruane Date: Tue, 22 Mar 2022 13:04:26 -0600 Message-ID: To: Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Tue, 22 Mar 2022 19:27:52 +0000 Subject: [bitcoin-dev] mempool transaction witness-replacement 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: Tue, 22 Mar 2022 19:05:07 -0000 Greetings list, This is my first time posting here. Question for you: Should the Bitcoin Core mempool replace an existing transaction with one that has the same txid (having the same effect, same spends and outputs) but a sufficiently smaller witness (different wtxid) and thus a higher feerate? This is what https://github.com/bitcoin/bitcoin/pull/24007 proposes, and I'd like to get opinions on two questions: 1. Is this a beneficial change? Specifically, is anyone creating an application that would broadcast transactions with the same txid but different witnesses as an earlier transaction? 2. If this change has benefit, what should be considered a sufficiently better feerate or reduction in witness size? An advantage of this mempool-accept policy change is that it's miner-incentive compatible (miners would prefer to mine a transaction with a higher feerate). But there is of course a code complexity cost, and transaction-relay DoS concern. Being miner-incentive compatible is good, but is that sufficient justification for merging? I'm posting to the mailing list in hopes that there are use-cases that we (the PR authors) aren't aware of. Please reply here or on the PR if you can think of any. A perhaps subtle advantage: This PR may provide a defense against a mempool pinning attack: if you have a transaction shared with other parties, and one of them broadcasts the transaction with a bloated witness (thus intentionally reducing the feerate in hopes of delaying or preventing confirmation), you currently have no way to change it. If there is an application out there that uses same-txid-different-witness transactions shared between counterparties, this PR would help make those applications safe. Question 2 gets at a DoS tradeoff: If the new transaction may have only a very slightly smaller witness, an attacker might re-broadcast it many times, consuming a lot of relay bandwidth, and CPU to update the mempool. On the other hand, if the new transaction must have a much smaller witness, then it wouldn't be possible to replace a transaction with a beneficially-smaller one. This could be a per-node setting, but it's desirable for the node network to largely agree on relay policies (although a configuration option might be useful for testing and experimentation). Background: Bip125 (Replace-by-fee) allows an incoming transaction to replace one or more existing conflicting transactions if certain DoS-mitigation conditions are met: https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md Witness-replacement is similar to RBF, but differs in a few ways: - RBF rule 4 requires an absolute fee increase, which is not possible if the txid isn't changing (since the inputs, outputs, and amounts must be the same). So if transaction witness-replacement (same txid but different wtxid) is allowed, it can't be considered just a special case of an RBF, although it may have some similar policies (and for the same reasons). - With witness-replacement, it's not necessary to evict mempool descendant transactions because their inputs' txid references to their parent (who is being replaced) remain valid. - The new transaction replaces exactly one existing transaction since the inputs are the same. (In general, with RBF, the new transaction may conflict-out multiple existing mempool transactions, namely, all that spend the same outputs as the new transaction.) - RBF requires the original transaction to signal replaceability (rule 1). This is so that recipients are warned that their payment may disappear if the transaction is replaced. But signaling isn't required by witness-replacement since the outputs can't change (the descendants remain valid). Thanks for your time! Larry Ruane (with lots of help from Gloria Zhao)