This question was inspired by this recent mempool phenomenon: some transactions were left out from blocks even when they had a competitive fee-rate simply because they had a positive sigop count and the max sigop count was reached before the block template was totally filled. Whatever empty space remained was filled using zero sigop txs.
It seems that miners have to solve a knapsack-like problem where they are constrained by two hard limits: one is the size of the block and the other is the maximum amount of sigops. The former is the one actually optimized for in the standard mining algorithm, and the latter is more-or-less considered due to the content of this PR, which penalizes the size of a transaction if it has a high sigop count.
I have two questions:
- Suppose the mempool contained no zero sigop transactions and that the selection algorithm constructed a block template consisting of high sigop count transactions only but lots of available space. Is it guaranteed by the choice of
nBytesPerSigOpthat this block template is more convenient for miners that one where the block is full and high sigop transactions are avoided?
Judging by this answer it'd seem as if indeed the miner could earn slightly more if they did some clever work, but that it'd be hard for it to actually happen in practice.
- Why isn't the standard mempool-based fee estimation algorithm sigop-aware? In a context in which there are lots of high sigop transactions with competitive fee-rates, there are two different next block fees depending on whether the transaction one is about to craft has a positive sigop count or not.