eth, miner: fix enforcing the minimum miner tip

[karalabe]

Geth originally enforced transaction gas prices and tips in the transaction pool. This seemed like an elegant way to avoid having to check the same thing in two different places. By default the pool (and hence miner) admitted 1 wei tip transactions, and when mining was started, that was increased to whatever the user set, or 1gwei by default.

Unfortunately, the merge kind of broke this mechanism. Since post-merge mining is not requested to be "turned on" in Geth, rather blocks are sometimes produced on demand via the beacon client, the mechanism that flipped the pool from non-mining-node mode to mining-node mode never got triggered. The effect is that all validating Geth nodes accept 1 wei tip transactions into the pool currently, and because the miner doens't do a follow-up enforcement, those will get included in a block blindly...

Now, in practice, the transactions are still sorted in highest-tip order, so the effect isn't really relevant on mainnet, or anywhere really where the pool has enough proper transactions to fill up a block. The issue is mostly relevant in testnets, private nets, or Geth forks where the network might not be completely saturated. In those cases, even though Geth supports a --miner.gasprice flag, that gets elegantly ignored (tho you could still use txpool.gasprice to have the desired side effect).

The fix for this issue is not so obvious. Restoring the previous mechanism of the pool enforcing the tip is problematic, since there's no startup marker in Geth that would signal that the machine will be mining, so start enforcing stricter limits. Sure, we could require users to pass in --mine, but it seems like an arbitrary useless thing to need. We could also start enforcing gas tips the first time a block is requested from us, but it feels wrong to all of a sudden do a big txpool filtering exactly when we need to build a block and can't afford to waste time.

The solution proposed in this PR is to go back to a less simple way, that of having a second filtering step within a miner that can enforce tips independent of the pool. Cost wise this doesn't add anything to the current "faulty" behavior. What this would mean is that by default even block producing nodes accept and propagate txs down to 1 wei tip (as long as it fits into the 4/6K limit); but anything below the needed limit would get filtered out in the miner itself now.

Side note: if the user calls miner.setGasPrice API method, that will enforce the price on both the miner and the txpool. Whilst we could drop the enforcement from the pool, I felt that we should aim to keep as much behavior as we can unchanged.

[rjl493456442]

Some tests are failing because of the additional restriction, please fix them.

[karalabe]

@rjl493456442 Fixed + added a mechanism to the simulated backend to specifically set the minimum gas tip needed by the miner.

We'll have a small breakage here unfortunately. Previously the simulated backend used a gas tip of 0; and the buggy conversion due to this PR's root issue also kept supporting that 0 tip. However, with the miner fixed in the live node, the new simulated backend which wraps a live node will start rejecting 0 tips.

Currently it is not possible to make the miner accept 0 tip in a live node and I didn't want to add a hack to the simulated backend to make it possible there. Since ideally we want the sim to follow live as close as possible, I think we'll need to live with potentially breaking a few eggs here and there.

That said, abigen for example retrieves the prices and tips from the node implicitly, so it should not break in the default cases, only for use cases where the user very explicitly specified 0 gas tips (or below 1 gwei). Still, even the 1 gwei one can be fixed with the new option introduced. So really only the exact 0 price is problematic.

PTAL

[MariusVanDerWijden]

LGTM

[ghost]

@karalabe @MariusVanDerWijden Think I was the first to find the issue but you ignored me back then.... #28487