path: root/8c/23d6963867ab1232cfe7ccac6e61085e0682f4

Return-Path: <darosior@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 04AE7C000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 19:57:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id DF51F417C2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 19:57:31 +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_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id j55Eis4Yu2Xg
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 19:57:30 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19])
 by smtp4.osuosl.org (Postfix) with ESMTPS id DE48741746
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 22 Mar 2022 19:57:29 +0000 (UTC)
Date: Tue, 22 Mar 2022 19:57:23 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1647979046;
 bh=HytvPx/FHPwK9GtL7q49APKnwB5TPXBHM8omOy/5v0g=;
 h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References:
 From:To:Cc:Date:Subject:Reply-To:Feedback-ID:Message-ID;
 b=0mH++HazEScRspqp/pJjab+iruDp7lgNUEV73kLvsj2B09qBh47S3yfakgeXoEkWu
 966EutXYR0x9lh8KzCHk7iJ7I1tnCGhRskI5M1h6WVsLrVaQt5IWFIbl9Tc8s7eTQy
 BB35qzwOa89WNS+35n+s172EHjk1MKk5VHiB0yNMrLjtpF6aN0b5zWRrPVilwcDVIX
 wjSbCUFAPiNI3Th4WeBFwdJXRlBZ1POBKLh3SzbkROkYXI9QpdkkImbSvZfCE6Y/Ge
 eM2mSUak0tP305WyR+gNsJAVsuRJuPh+O7+tPbp3Fj2xCrZU7EV2CSc8qqLVVe0I9r
 cgHJUX3VkkmTw==
To: Larry Ruane <larryruane@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: darosior <darosior@protonmail.com>
Reply-To: darosior <darosior@protonmail.com>
Message-ID: <dsYqg51rjma__su9a8-7oZD8f5NkNMfKCYwjTvYkzwgvFS1qarplsi9UToewZLbZ6lCWdLrHSs7-88KBkocBy_mKCztF_Y683ELvirVERpw=@protonmail.com>
In-Reply-To: <CAEpYn+eOv7xRkTA2RfpC+ps2ykyvjfZ-iY8-4z9nHov-dNLimw@mail.gmail.com>
References: <CAEpYn+eOv7xRkTA2RfpC+ps2ykyvjfZ-iY8-4z9nHov-dNLimw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 22 Mar 2022 21:14:33 +0000
Subject: Re: [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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2022 19:57:32 -0000

Hi Larry,


Thanks for bringing this up. I'm curious to know if this is helpful for pin=
ning as long as you have a way to
statically analyze Script to prevent witness stuffing [0]. I agree it *coul=
d* still be useful for miners, but
subject to all the complications of RBF.

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

There is more to be "miner-incentive compatible" than increasing feerate. F=
or instance, the latest RBF
discussions made the miner incentive to maximize absolute fees more well kn=
own. I think the same goes for
witness replacement: if you don't have as many MBs of transaction you are c=
omfortable with in your mempool,
you don't want it to shrink further.


Antoine

[0] See the 'Malleability' section of https://bitcoin.sipa.be/miniscript/. =
Note however this currently only
    applies to third party malleability (in pinning attacks the aversary is=
 internal to the contract). On the
    other hand Miniscript already allows you to get the maximum satisfactio=
n size, so you can cover for the worst
    case scenario already.

------- Original Message -------

Le mardi 22 mars 2022 =C3=A0 8:04 PM, Larry Ruane via bitcoin-dev <bitcoin-=
dev@lists.linuxfoundation.org> a =C3=A9crit :

> 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-witnes=
s
>
> 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 wi=
th
>
> 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-replace=
ments.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)
>
> _______________________________________________
>
> bitcoin-dev mailing list
>
> bitcoin-dev@lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev