First of all, there is an “alternatives” section of the v3 BIP. It describes common suggestions and why they do not work, are good ideas but can only be applied to limited topologies (which is what v3 is for), are only feasible to implement generally after cluster mempool (which is a step after v3), or are not conflicting with this proposal.
I’d also encourage people to read the discussions linked in the BIP and PR. There is a lot of context and history, but there’s tons of publicly-viewable text to build background on it.
General Replace by Feerate
“Get rid of Rule 3+4 and use feerate instead” is a good place to start brainstorming, but it’s free relay / DoSy. Not much new to say here.
Replace by Feerate and having 2 sets of RBF rules
There has also been lots of exploration of the idea “in certain special situations, use a different set of rules based on {feerate, miner score}.” One-Shot Replace by Feerate is one. There’s also “[PROPOSAL] Emergency RBF (BIP 125)” and “Fees in Next Block and Feerate for the Rest of the Mempool”, among others.
For me, a key takeaway from those discussions was:
- A replacement should confirm “faster” than the replacee. Users should not be paying higher fees and feerate only to have their transaction confirm slower.
- We should have a “miner score” or some miner incentive compatibility metric that we can use to compare the replacement and replacee (obviously individual feerate does not work). And we should require that replacements increase miner score.
Some major problems with this include:
- Free relay is usually still present. See this or this on infinite replacements. Intuitively, having 2 sets of rules designed to bypass each other can easily result in this kind of loop. I’m not saying it’s impossible to design 2 that don’t do this, but just some intuition if you don’t want to go through the math.
- The notion of “would confirm soon” or “in the top N portion of the mempool” such that it’s safe and useful to employ this other set of rules is not well-defined. It’s also not at all easy to implement (see next point).
- The mempool as it exists to today doesn’t support an efficient way to calculate “miner score” or incentive compatibility, due to unbounded cluster sizes.
- There is no static calculation using the cached ancestor set values. Lots of people propose ancestor feerate (including myself, see this PR which I do think is deserving of the “half baked” criticism), but it doesn’t work. Also see this more deatiled breakdown of 4 options for static calculation.
- Actually calculating the miner score (see this implementation for privileged wallet which needs to halt at 500) is too computationally complex to include as a step in mempool validation.
- I’ve proposed meeting halfway and caching the top block’s worth. That is also considered too complex.
One advantage of cluster mempool is being able to calculate things like miner score and incentive compatibility across the mempool. Similarly, one advantage of v3 is being able to do this before cluster mempool because of restricted topology. Before people took on the challenge of designing and implementing cluster mempool, I had been framing v3 as “cluster limits” without having to implement cluster limits, as it’s one of the only ways to codify a cluster limit (count=2) using existing package limits (anc=2, desc=2. Once you go up to 3, you can have infinite clusters again). Another advantage of v3 is that it helps unblock cluster mempool, which is imo a no-brainer.
In summary, I don’t think the One-Shot Replace by Feerate proposal works (i.e. doesn’t have a free relay problem) and is feasible to implement accurately. The path of upgrades proposed (v3 package RBF, v3 sibling eviction, 1p1c package relay, cluster mempool) is the most complete solution by far. V3 is simple (and perhaps that leads people to think it is not well thought out?) and useful both as a building block and for solving specific problems in general.