Date: Tue, 22 Mar 2022 19:57:23 +0000
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
Subject: Re: [bitcoin-dev] mempool transaction witness-replacement
Precedence: list

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