Proposal: Watchdog for miners including failing bundles

[Randall4]

Background

Because of EIP-1559, end users of the Flashbots relay now have to place trust in miners when it comes to avoiding reverting transactions from being included. Prior to EIP-1559, the cost of including a reverting Flashbots transaction was paid by the miners who included it, if the gas price of the transaction was 0. Now, the basefee of all Flashbots transactions are paid by users.

Problem

Under EIP-1559, users can avoid the risk of paying a basefee when they are "uncled" by sending the miner payment via a coinbase transfer and setting the priority fee to 0 wei. If uncled, these transactions will be neither broadcast through the mempool nor included in future blocks because the default implementation of geth does not include transactions that have a priority fee of 0.

Unfortunately for users, this is not actually true in practice. Miners often mix and match the rules using custom implementations of mev-geth, and some of these implementations violate the Flashbots Fair Market Principles. Specifically, miners violate both the "Correctness" and "Privacy" principles if they include reverting Flashbots transactions - not necessarily intact bundles - with a priority fee of 0.

The "Correctness" principle is broken because it lets bundles fail without regard for the revertingTxHashes list:

Transactions in the bundle MUST execute without failure (return status 1 on transaction receipts) unless their hashes are included in the revertingTxHashes list.

The "Privacy" principle is broken because failed-trade privacy is not upheld:

Failed-trade privacy: No MEV bundle received by the miner is ever disclosed to any third party after it has not been selected for a block.

Ultimately, when a reverting Flashbots bundle is included, everybody loses: the Ethereum blockchain needlessly bloats in state a little bit, the user that sent the transaction loses ETH - sometimes a significant amount, and using the Flashbots relay is visibly more risky.

Including reverting zero-priority transactions is definitely "bad behaviour" in the view of the FFMP document.

Solution

I propose that Flashbots create a watchdog application that monitors for miners who violate the reverting transaction rule in this way. This likely can be done by simply finding Flashbots-enabled miners who sometimes include reverting transactions with a priority fee of 0 in their blocks. I also propose that, when this is detected, the miner at fault be blacklisted until they have indicated that they understood what was wrong and acknowledged that they fixed their code.

The aim is to reduce user risk, which by now no longer affects just a camp of MEV searchers but also includes routers aimed to help more causal ETH users send private transactions.

Appendix

Here is an example of a mined block that contains a number of reverting Flashbots transactions with priority fees of 0. Because of the way transactions are ordered by descending priority fee, these will always be at the tail end of a block:
https://etherscan.io/txs?block=13567293

I don't know exactly how many miners that do this, but I do know that this particular miner has been including reverting bundles in this way ever since EIP-1559, and the block numbers of the reverting transactions are often far beyond the block numbers specified by the bundles.

[microbecode]

I'm not sure your sentence "Ultimately, when a reverting Flashbots bundle is included, everybody loses" is correct. What do the miners lose?

[Randall4]

When I wrote that sentence, I believe I was thinking in the context of blockchain storage. It's a useless transaction that every ETH node will have to process and store forever.

Miners don't have a direct incentive to exclude them except that it might bloat their own transaction pools, depending on how many they choose to keep.