This query was impressed by this current mempool phenomenon: some transactions have been not noted from blocks even after they had a aggressive fee-rate just because they’d a constructive sigop depend and the max sigop depend was reached earlier than the block template was completely crammed. No matter empty area remained was crammed utilizing zero sigop txs.
It appears that evidently miners have to resolve a knapsack-like drawback the place they’re constrained by two exhausting limits: one is the dimensions of the block and the opposite is the utmost quantity of sigops. The previous is the one truly optimized for in the usual mining algorithm, and the latter is more-or-less thought of because of the content material of this PR, which penalizes the dimensions of a transaction if it has a excessive sigop depend.
Q1: Suppose the mempool contained no zero sigop transactions and that
the choice algorithm constructed a block template consisting of
excessive sigop depend transactions solely however numerous accessible area. Is it
assured by the selection ofnBytesPerSigOpthat this block template
is extra handy for miners that one the place the block is full and
excessive sigop transactions are prevented?
Judging by this reply it’d appear as if certainly the miner might earn barely extra in the event that they did some intelligent work, however that it might be exhausting for it to truly occur in observe.
Q2: Why is not the usual mempool-based payment estimation algorithm
sigop-aware? In a context during which there are many excessive sigop
transactions with aggressive fee-rates, there are two completely different subsequent
block charges relying on whether or not the transaction one is about to craft
has a constructive sigop depend or not.
