Cute cherry-picks, but there’s much more to it.
1.
Centralized block templates (hurts censorship resistance)
You need to explain how this would hurt censorship resistance. By design block templates are “centralized” with block producers, and now we have specialization so pools are the producers and miners are the hashers. Hashers can easily “uncentralize” their hash by running their own pool. What does MEV change here?
If most apps have simple stupid MEV then how would some pool gain advantage over another? They’d all be equally capable to extract MEV, just as they’re equally capable to collect TX fees. The whole boogeyman depends on there being some imaginary super complex MEV that only the most genius of pools (or specialists) can extract and gain an edge.
I think Rearden made an argument somewhere that for this reason MEV on BCH is less dangerous than it would be on BTC with CAT/CTV, because on BCH ScriptVM is more expressive and makes it more obvious how/where to extract MEV.
Novel MEV extraction method would be akin to a new ASIC being exclusively used by the manufacturer: you get an edge only until others catch up. And the chain is transparent - so you can’t really hide what you’re doing much. With ASICs it could take time for others to reverse-engineer.
When I brought it up before him, he was actually in agreement with this view.
If your script engine is expressive enough that with just a few bytes the creators and spenders of UTXOs can precisely specify the conditions in which their transaction is to be valid with zero ambiguity, most types of MEV can’t be harvested by miners (the changes they would make to transactions would make them invalid since the users are able to precisely specify their intentions).
If we just add CAT to bitcoin for example, then to get the level of precision needed to eliminate MEV from an application might be too costly such that the cost of miners getting the MEV might be lower to the application users than the cost of preventing it through script.
This is not a black and white thing, but a continuum.
I don’t know Eth MEV well, but I do wonder if the complexity of authoring Eth contracts contributes to the prevalence of MEV because people use standardized contracts that don’t fully encapsulate their intentions rather than risking contract bugs.
The 2nd link is about Ethereum EVM which is mostly NOT APPLICABLE to us. On Ethereum the MEV’d block is all-or-nothing. The validator carefully assembled a block to extract whatever he could to himself, and others can’t simply reassemble it to replace his block with a block extracting to them instead.
On BCH - all miners can try farm MEV on individual TXs without breaking others, they can more easily “steal” MEV extracted by another miner. If the MEV is extracting value via TX fees, then other miners can attempt to reorg his block with all the same transactions and claim the TX fees themselves, making MEV more uncertain.
In a way “instant finality” enables the problem it claims to be solving. If 3rd parties privately communicate MEV to a validator and they announce a block, it being “final” means others can’t “steal” the MEV for themselves.
On PoW chains - they can, which is a disincentive to 3rd parties making deals with pools and undermines the foundations of your “dark mempool” theory. Why should a 3rd party MEV specialist not just give their MEV’d transactions to ALL the miners, rather than take chances with whether the found MEV will still be valid if some other miner finds a block.
A public kind of huge MEV did happen in the past on BCH, soon after SegWit recovery activation, where the initial bounty was too big to resist fighting over:
Based on publicly available data, the reorg was caused by a hashpower struggle between two miners, the outcome of which was $1.39M (3655 BCH) being sent to the originally intended recipients and $82k (216 BCH) being sent to unknown addresses. – source
Since then, these transactions have been a regular occurrence. This is pure MEV, what problems is it causing for anyone?
The above one-off 3.6k BCH MEV highlights a real problem with outsized fees - that of network delays for everyone while miners fight it out. But instead of investigating other solutions you just want to plug it with Avalanche. I already brought up an alternative to your attention. How about actually updating, or will you continue to shill Avalanche like a broken record? Here’s more on that alternative: On RSK's Block Reward Smoothing | Rootstock (RSK)
2.
Compact Blocks collapsing due to dark mempools (10x hit to scalability)
Again you make the mistake in thinking Account-based MEV directly maps to UTXO MEV.
Your first link says something truthful: yes, if mempools are not in sync then block propagation will take longer. Well no shit, Sherlock, everyone knows that. But then you follow with “see, it’s happening on ETH, therefore big problem for BCH” stubbornly ignoring significant differences in architecture so you can doompost and… shill Avalanche.
And again you show 0 evidence of updating your talking points based on past discussions (1 2), and continue to make bombastic claims like a broken record, about how we will all burn in MEV hell if we don’t listen to your warning. It’s all so tiresome.
3.
Unconfirmed transaction chains built on UTXOs that will be nuked (double-spend risk)
Yes, this is a real problem for users - but only to those users who partake in building on top of a nukeable TX, detail conveniently missing from your analysis. I too suspect that some of it could be happening on Cardano and Ergon, but I’m not trusting AI-generated slop. Find real research if you want to point to those chains as examples.
Pure P2PKH 0-conf chains are fine (P2PKH still makes about 99% of our TXs), and they can benefit from DSPs and ZCEs, completely unaffected by MEV happening in DeFi zones. Even you use same wallet for both: as long as you have 1 confirmed UTXO in your wallet, you can go on a 0-conf shopping spree with no risk of getting nuked.
DeFi users will have a choice: partake in platforms where sequence is somehow enforced by 3rd parties (e.g. platform signing off on trades) or partake in probabilistic platforms like Cauldron. MEV happening on Cauldron won’t really create problems for anyone else, and if it’s too much trouble for Cauldron users: then the users will flock to other solutions.
