Miner transaction selection - how are sigops considered?

Question

There is a limit on how much a block can sigop (set to 80000?). There is also a limit on how much a single transaction can sigop (set to 16000?). It thus seems possible (and if it's not possible, the remaining of this question is void, but then how is it prevented?) that an attacker submits five special transactions to consume the whole block sigop limit.

If such attacking transactions are using very generous fees per byte, if the miner chooses which transactions to include in a block based on fee per byte metric, it would include the attacking transactions in a block, getting relatively huge fees per byte, but not filling the block because of sigop limit. This would mean that the miner could get more in fees if it avoided attacking transactions, but the question is whether such selection avoidance is implemented by default.

Answer 1

For the purpose of mining transaction selection Bitcoin Core converts sigops into an effective weight value based on the ratio of the limits. If the weight implied by the sigops count is higher than the true weight, the higher value is used for fee handling calculations. On any kind of remotely sane transaction this has essentially no effect, but eliminates your suggested attack.

See the -bytespersigop setting. The default value of 20 is somewhat less than the ratio of the limits, because the true value distorts costing for non-attack transactions a bit too much, and the smaller value is sufficient to make this kind of attack uninteresting.

It does mean that in the presence of attack transactions paying moderately high fees a miner might earn slightly less income than one that was more savvy about solving this multidimensional optimization problem. However, since the attack doesn't work, the transactions don't get made, making this slightly sub-optimal behavior irrelevant.

The tapscript proposal specifically doesn't use sigops at all to avoid these sorts of issues.