Consider replacing mempool transactions based on the transaction fee

[jvff]

Motivation

As of #2765, mempool transactions are rejected if they spend a UTXO that's already spent or a nullifier that's already revealed by another transaction in the mempool. However, this prevents a user from replacing a transaction with another one by setting a higher transaction fee. We should consider adding support for replacing a transaction based on the transaction fee.

There might be more than one conflict when adding a transaction, so a more complete version might be to build two sets of transactions and then select the set that has a higher overall fee (or the set that provides a larger profit to a miner).

Specifications

Zcash implemented ZIP-203 (transaction expiry heights) instead of fee replacement.

So we don't need to implement this ticket, and we might decide not to do it at all.
(zcashd decided not to do it.)

Designs

Related Work

[str4d]

We considered this for zcashd (RBF was one of the potential backports from upstream Bitcoin Core), and decided it was too complex and ad-hoc a mechanism for the benefits it claimed to provide. We instead deployed ZIP 203 with Overwinter which added a transaction expiry field, to give transaction creators explicit consensus control over whether a transaction should be allowed to persist indefinitely in the mempool or not. See zcash/zcash#754 for the associated discussion. With the defaults recommended in ZIP 203 (which thus far, all shielded transactions have followed), transactions cannot become stuck in the mempool.

[dconnolly]

https://zips.z.cash/zip-0203

[daira]

Note however that expiry is optional (the transaction creator can set nExpiryHeight to 0, or with almost the same effect, to a block height far in the future). If ZIP 401 is implemented then newer transactions will tend to displace older ones when the mempool becomes "full". Also, the mempool is cleared on a network upgrade.

(Previously, zcashd would also clear the mempool on a restart, but I think that is no longer the case.)

[dconnolly]

(Previously, zcashd would also clear the mempool on a restart, but I think that is no longer the case.)

No longer? That's our current plan (rather, cavalierly blow away mempool state on shutdown/restart, on network upgrade, if we need to catch up with chain tip, etc)

[daira]

Sorry I'm mistaken, zcashd does still clear the mempool on restart. I was thinking of something else (persisting the banlist, I think).

[teor2345]

(Previously, zcashd would also clear the mempool on a restart, but I think that is no longer the case.)

No longer? That's our current plan (rather, cavalierly blow away mempool state on shutdown/restart, on network upgrade, if we need to catch up with chain tip, etc)

Zebra can afford to blow away the mempool because it eagerly crawls peer mempools, it shares newly verified transactions with peers, and it's connected to lots of peers.

So there's very little risk of transaction loss.

[teor2345]

I've marked this ticket as optional, based on zcashd engineer feedback.