<blockquote>
<p>Q1: 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 nBytesPerSigOp that this block template is more convenient for miners that one where the block is full and high sigop transactions are avoided?</p>
</blockquote>
<p>There are no guarantees that templates generated by Bitcoin Core will be optimal.</p>
<p>The adjusted vsize introduced by PR #8365 significantly underweights the contribution of high sigop transactions to the sigop limit, charging only 40% of the equivalent usage of the weight limit.</p>
<p>This means that in such extreme scenarios, the miner would likely lose out on fees compared to a weight-maximizing block.</p>
<p>However in practice it's very rare for sigops to be a limiting factor in template construction. Over the last 10,000 blocks (between heights 815316 and 825316), only 62 were constrained by the sigop limit, despite an abnormally large number of high sigop transactions during that period.</p>
<p>As long as sigops are not a limiting factor, it's more profitable to accept the additional fees incurred by the <code>bytespersigop</code> adjustment than to exclude them by raising the penalty further. So the current default of 20 weight units per sigop is likely to be more profitable than a &quot;fair&quot; cost of 50 WU/sigop most of the time.</p>
<blockquote>
<p>Q2: 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.</p>
</blockquote>
<p>I suspect that nobody anticipated this scenario would actually occur, or thought it would be too rare to justify the additional effort and complexity.</p>

CC BY-SA 4.0
2024-01-11T16:05:47.707Z
2024-01-11T16:06:49.477Z
2024-01-11T16:06:49.477Z
mononaut
<p>This question was inspired by this <a href="https://twitter.com/mononautical/status/1743274489893282187" rel="nofollow noreferrer">recent mempool phenomenon</a>: 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.</p>
<p>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 <a href="https://github.com/bitcoin/bitcoin/pull/8365" rel="nofollow noreferrer">this PR</a>, which penalizes the size of a transaction if it has a high sigop count.</p>
<p>I have two questions:</p>
<ol>
<li>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 <code>nBytesPerSigOp</code> that this block template is more convenient for miners that one where the block is full and high sigop transactions are avoided?<br />
Judging by <a href="https://bitcoin.stackexchange.com/questions/87841/miner-transaction-selection-how-are-sigops-considered">this answer</a> 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.</li>
<li>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.</li>
</ol>

CC BY-SA 4.0
2024-01-11T16:16:47.473Z
The fee estimator uses virtual size, which is influenced by the number of sigops. Why do you say it's not sigop-aware?
Antoine Poinsot
CC BY-SA 4.0
2024-01-11T17:02:23.473Z
@AntoinePoinsot True, my question was poorly worded. What I meant to say is that in the case that sigops are a limiting factor, as mononaut explains in their answer, there are in fact two next block fee-rates: one for zero sigop txs and one for non-zero sigop txs.
Cosmik Debris
<bitcoin-core><mempool><transaction-selection><signature-operations>
Sigop count and its influence on transaction selection
Cosmik Debris
# Sigop count and its influence on transaction selection

(Asked by: username_0 on 2024-01-08)

This question was inspired by this [recent mempool phenomenon](https://twitter.com/mononautical/status/1743274489893282187): 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](https://github.com/bitcoin/bitcoin/pull/8365), which penalizes the size of a transaction if it has a high sigop count.

I have two questions:

1. 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 `nBytesPerSigOp` that 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](https://bitcoin.stackexchange.com/questions/87841/miner-transaction-selection-how-are-sigops-considered) 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.
2. 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.

**Tags:** bitcoin-core, mempool, transaction-selection, signature-operations

> **Comments:**
> **username_1**: The fee estimator uses virtual size, which is influenced by the number of sigops. Why do you say it's not sigop-aware?  
> **username_0**: @username_1 True, my question was poorly worded. What I meant to say is that in the case that sigops are a limiting factor, as username_2 explains in their answer, there are in fact two next block fee-rates: one for zero sigop txs and one for non-zero sigop txs.  

---

## 1 answers

### Answer by username_2 on 2024-01-11. Score: 5 | Accepted answer

> Q1: 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 nBytesPerSigOp that this block template is more convenient for miners that one where the block is full and high sigop transactions are avoided?

There are no guarantees that templates generated by Bitcoin Core will be optimal.

The adjusted vsize introduced by PR #8365 significantly underweights the contribution of high sigop transactions to the sigop limit, charging only 40% of the equivalent usage of the weight limit.

This means that in such extreme scenarios, the miner would likely lose out on fees compared to a weight-maximizing block.

However in practice it's very rare for sigops to be a limiting factor in template construction. Over the last 10,000 blocks (between heights 815316 and 825316), only 62 were constrained by the sigop limit, despite an abnormally large number of high sigop transactions during that period.

As long as sigops are not a limiting factor, it's more profitable to accept the additional fees incurred by the `bytespersigop` adjustment than to exclude them by raising the penalty further. So the current default of 20 weight units per sigop is likely to be more profitable than a "fair" cost of 50 WU/sigop most of the time.

> Q2: 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.

I suspect that nobody anticipated this scenario would actually occur, or thought it would be too rare to justify the additional effort and complexity.


---

