Re: [bitcoin-dev] mempool transaction witness-replacement

From: darosior <darosior@protonmail•com>
To: Larry Ruane <larryruane@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] mempool transaction witness-replacement
Date: Tue, 22 Mar 2022 19:57:23 +0000	[thread overview]
Message-ID: <dsYqg51rjma__su9a8-7oZD8f5NkNMfKCYwjTvYkzwgvFS1qarplsi9UToewZLbZ6lCWdLrHSs7-88KBkocBy_mKCztF_Y683ELvirVERpw=@protonmail.com> (raw)
In-Reply-To: <CAEpYn+eOv7xRkTA2RfpC+ps2ykyvjfZ-iY8-4z9nHov-dNLimw@mail.gmail.com>

Hi Larry,

Thanks for bringing this up. I'm curious to know if this is helpful for pinning as long as you have a way to
statically analyze Script to prevent witness stuffing [0]. I agree it *could* 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. For instance, the latest RBF
discussions made the miner incentive to maximize absolute fees more well known. I think the same goes for
witness replacement: if you don't have as many MBs of transaction you are comfortable 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 satisfaction size, so you can cover for the worst
    case scenario already.

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

Le mardi 22 mars 2022 à 8:04 PM, Larry Ruane via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> a écrit :

> 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)
>
> _______________________________________________
>
> bitcoin-dev mailing list
>
> bitcoin-dev@lists•linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev