miner: fix mev gas price calc when bundle replaces mempool tx

[bsh98]

📝 Summary

Currently, if a bundle includes a transaction that has the same sender and nonce as a transaction in the mempool (i.e. attempting to replace a mempool transaction with a bundle transaction), the gas fees from the bundle transaction will not be counted towards the bundle's value. This PR compares transaction hashes instead of transaction nonces when checking if a bundle transaction is present in the mempool. This PR allows for replacing a mempool transaction with a bundle transaction (and having its value counted towards the bundle value) when the effective gas price of the bundle transaction is larger than the gas price of the mempool transaction.

Motivation

There are cases when a searcher may want to re-use a nonce from a mempool transaction in a bundle. For example, a searcher may want to privately replace a pending transaction or move a PGA to a bundle auction.

Variations

Another approach would be to only count the gas fees if the bundle transaction's effective gas price (coinbaseDiff + gasFees) / gasUsed is greater than N% (configured price bump) larger than the mempool transaction's gas price. This would closely follow the replacement logic of the mempool.

builder/core/tx_list.go

Lines 293 to 296 in 8caba1f

	// thresholdTip = oldTip * (100 + priceBump) / 100
	b := big.NewInt(100)
	thresholdFeeCap := aFeeCap.Div(aFeeCap, b)
	thresholdTip := aTip.Div(aTip, b)

This would avoid allowing "cheap" cancellations/replacements.

Implications

This could incentivize searchers to include replaced transactions in their bundles. Possible solution: 947f59a

---

• I have seen and agree to CONTRIBUTING.md

[Ruteri]

While I love the idea, correct me if I'm wrong in thinking that a transaction can overwrite a transaction with the same nonce, removing it from the pending list.
So you'd actually still count the old, replaced transactions as not having been in the pending. This would require keeping track of the dropped transactions.

[bsh98]

While I love the idea, correct me if I'm wrong in thinking that a transaction can overwrite a transaction with the same nonce, removing it from the pending list. So you'd actually still count the old, replaced transactions as not having been in the pending. This would require keeping track of the dropped transactions.

Apologies for the late reply and I appreciate the response.

Yes, you are correct in that just comparing transaction hashes could lead to a transaction not being counted as pending (I didn't catch this in my first commit). However, is it safe to assume that a transaction could only have been dropped and replaced if it had a lower gas price than the current pending transaction? I believe this would allow you to count a bundle transaction as known/seen if the gas price is less than or equal to the current pending transaction. This would avoid having to keep track of all dropped transactions. If a transaction was dropped for another reason (e.g. pool lifetime exceeded), it wouldn't be counted as pending anyways. In other words, if a bundle includes a transaction with the same account + nonce as a pending transaction, it is marked as known unless the effective gas price is higher (i.e. effectively replacing the pending transaction).

[Ruteri]

However, is it safe to assume that a transaction could only have been dropped and replaced if it had a lower gas price than the current pending transaction?

Yes, but we still don't want to count that gas, even if it's lower than what we have now in the mempool. This still allows stuffing as far as I can tell.

[bsh98]

Yes, but we still don't want to count that gas, even if it's lower than what we have now in the mempool.

Agreed! The goal is to not count the gas fees if the effective gas price is less than or equal to the transaction in the mempool. If it's safe to assume that a transaction could have only been dropped if it had a lower gas price, then we should safely be able to prevent stuffing a dropped transaction by marking all underpriced transactions as seen.

builder/miner/worker.go

Lines 1889 to 1901 in 660deaa

	} else if accountTx.Nonce() == txNonce && accountTx.Hash() != txHash {
	// Bundle is attempting to replace a transaction from the mempool.
	txTipValue := new(big.Int).Add(gasFeesTx, coinbaseDelta)
	txTipGasPrice := new(big.Int).Div(txTipValue, gasUsed)
	accountTxTipGasPrice := accountTx.EffectiveGasTipValue(env.header.BaseFee)
	if txTipGasPrice.Cmp(accountTxTipGasPrice) != 1 {
	// Replacement underpriced, so don't count the gas fees towards the bundle value.
	// This could mean that the transaction was already replaced in the mempool.
	// This prevents incentivising bundles to include replaced transactions.
	txInPendingPool = true
	}
	break
	}

We should only count the gas fees if the effective gas price is strictly greater than the transaction in the mempool. Apologies if I'm still missing an edge case or something major here— would it possible to provide an example of how this could allow stuffing?