Mempool requires dynamic fee txs to increase both tip and fee cap by price bump threshold

[PlasmaPower]

The comment here

go-ethereum/core/tx_list.go

Line 296 in 3526f69

// Have to ensure that either the new fee cap or tip is higher than the

says that increasing either the fee cap or the tip cap by the threshold is enough to accept the replacement. However, the code actually requires both be increased by the threshold, as either half of the if statement passing will lead to the return false, and the transaction being rejected for being an underpriced replacement.

I'm not sure if the comment or code is correct here, but one should definitely be updated so they're in sync. It seems to me like accepting a replacement tx which increases the tip by 15% but doesn't change the fee cap much (as the base fee is the largest part of the fee cap) makes sense, and the current code wouldn't accept many replacement transactions.

[PlasmaPower]

I just saw some discussion on this in the PR that introduced this code, https:/ethereum/go-ethereum/pull/22898/files#r636583352 . It seems like the current behavior is the desired behavior, so the comment should be updated.

[rjl493456442]

Yes, it's the expected behavior, otherwise attackers can always reassign a higher feecap to DDOS.
Do you want to open a PR to fix the comment?

[EdNoepel]

If the user supplied both maxFeePerGas and maxPriorityFeePerGas, replacements should be allowed when only maxPriorityFeePerGas is bumped (assuming effective gas has increased as appropriate). Requiring both to be bumped prevents use of the feecap as an arbitrarily high set-and-forget hard limit, harming the user experience. I see how the bumping feecap could allow a spam attack, but not the tip.

[mining-visualizer]

100% agree with your comments @EdNoepel. I think the current implementation is not well thought out. It should be possible to increase the maxPriorityFeePerGas only. Since doing so will directly cost the user more, spam attacks are not an issue.