<p>Yes, the maximum number of signature operations per block also need to change. It may change dynamically with the block size limit. The code currently assumes a ratio of MAX_BLOCK_SIZE to MAX_BLOCK_SIGOPS:</p>

<p>From <a href="https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/main.h#L59-L60" rel="nofollow">https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/main.h#L59-L60</a>:</p>

<pre><code>/** The maximum allowed number of signature check operations in a block (network rule) */
static const unsigned int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;
</code></pre>

<p>If this ratio were kept constant, then when the max block size was increased, the max signature operations would increase to:</p>

<pre><code>16.7 MB / 50 = 335,544 sig ops
</code></pre>

CC BY-SA 3.0
2015-01-23T14:51:50.077Z
2015-01-24T01:40:04.330Z
2015-01-24T01:40:04.330Z
morsecoder
<p>Yes, to make "megablocks" viable for anything besides block chain data storage, the sigops limit would need to be changed.  Simply increasing it would be the easiest option, but I suspect at least some developers would prefer to change how the sigop limit is calculated instead.</p>

<p>ECDSA signature-checking operations (sigops) are relatively time-consuming on moderns CPUs, so the goal of the sigop check is to make it easy to reject blocks (valid or not) that could otherwise take a significant amount of time to verify.  The sigop check is implemented naïvely: it simply looks for the OP_CHECKSIG and OP_CHECKMULTISIG op codes in transactions and calculates the number of sigops that will be required should that code be executed.  The aggregate number of sigops is calculated for the block containing the transactions.</p>

<p>You may have noticed the problem: for scripts like <a href="https://bitcoin.org/en/developer-guide#term-p2pkh" rel="nofollow">P2PKH</a>, OP_CHECKSIG can appear in one block as a pubkey script but the actual time-consuming signature checking operation takes place when the signature script is evaluated in another block.  In other words, it's possible to create a valid block today that requires performing more than 20,000 signature-checking operations but which has a sigops count of 0.</p>

<p>If we have to hard fork in megablocks, I think it possible that the opportunity will be taken to also change the sigops calculation formula---or to replace it with something different.</p>

CC BY-SA 3.0
2015-01-23T14:46:37.760Z
Why would sig ops of an output without an input be counted at all? You only need to run the script when you have an input that spends the prevout, it seems silly that it was ever calculated this way, unless there is a different kind of CPU exhaustion attack that I am not thinking of?
morsecoder
CC BY-SA 3.0
2015-01-23T15:09:24.597Z
No idea.  Satoshi [added the code](https://github.com/bitcoin/bitcoin/blame/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730/main.h#L509-L517) that's [still used](https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L783-L795).  (Note Satoshi's contributions are credited on GitHub to the user saracen; the commit log says s_nakamoto.)
David A. Harding
CC BY-SA 3.0
2015-01-24T01:38:35.480Z
@DavidA.Harding BTW, you first linked to CTransaction::GetSigOpCount, but what's actually called by the code at the second link is [CScript::GetSigOpCount](https://github.com/bitcoin/bitcoin/blob/f914f1a746d7f91951c1da262a4a749dd3ebfa71/src/script/script.cpp#L166).
Nick ODell
CC BY-SA 3.0
2015-01-23T08:17:55.010Z
2015-01-23T08:17:55.010Z
David A. Harding
<p><a href="https://github.com/gavinandresen" rel="nofollow noreferrer">Gavin Andresen</a>, one of the core developers, has discussed <a href="http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html" rel="nofollow noreferrer">increasing the block size to 16.7 MB</a> (and doubling that every two years).</p>

<p>The maximum number of signature operations per block is <a href="https://bitcoin.stackexchange.com/a/20725">currently set to 20000</a>:</p>

<blockquote>
  <p>[...] About the scriptSig being an arbitrary byte array, there is one caveat: the checksig operations in it are counted towards the block sigop limit (20000), so you probably don't want to accidentally trigger this. Making it a list of just push operations (including of the extranonce) avoids that.</p>
</blockquote>

<p>A back-of-the-envelope calculation tells me that there will be around 100K signature operations in a 16.7 MB block. Will the maximum number of signature operations per block also need to change?</p>

<signature><mining-technical-details><block-size-increase>
If block sizes go up, won't sigop limits have to change too?
Nick ODell
# If block sizes go up, won't sigop limits have to change too?

(Asked by: username_0 on 2015-01-23)

[Gavin Andresen](https://github.com/gavinandresen), one of the core developers, has discussed [increasing the block size to 16.7 MB](http://gavintech.blogspot.com/2015/01/twenty-megabytes-testing-results.html) (and doubling that every two years).

The maximum number of signature operations per block is [currently set to 20000](https://bitcoin.stackexchange.com/a/20725):

> [...] About the scriptSig being an arbitrary byte array, there is one caveat: the checksig operations in it are counted towards the block sigop limit (20000), so you probably don't want to accidentally trigger this. Making it a list of just push operations (including of the extranonce) avoids that.

A back-of-the-envelope calculation tells me that there will be around 100K signature operations in a 16.7 MB block. Will the maximum number of signature operations per block also need to change?

**Tags:** signature, mining-technical-details, block-size-increase


---

## 2 answers

### Answer by username_1 on 2015-01-23. Score: 3 | Accepted answer

Yes, the maximum number of signature operations per block also need to change. It may change dynamically with the block size limit. The code currently assumes a ratio of MAX\_BLOCK\_SIZE to MAX\_BLOCK\_SIGOPS:

From <https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/main.h#L59-L60>:

```
/** The maximum allowed number of signature check operations in a block (network rule) */
static const unsigned int MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;

```

If this ratio were kept constant, then when the max block size was increased, the max signature operations would increase to:

```
16.7 MB / 50 = 335,544 sig ops

```


---

### Answer by username_2 on 2015-01-23. Score: 1

Yes, to make "megablocks" viable for anything besides block chain data storage, the sigops limit would need to be changed. Simply increasing it would be the easiest option, but I suspect at least some developers would prefer to change how the sigop limit is calculated instead.

ECDSA signature-checking operations (sigops) are relatively time-consuming on moderns CPUs, so the goal of the sigop check is to make it easy to reject blocks (valid or not) that could otherwise take a significant amount of time to verify. The sigop check is implemented naïvely: it simply looks for the OP\_CHECKSIG and OP\_CHECKMULTISIG op codes in transactions and calculates the number of sigops that will be required should that code be executed. The aggregate number of sigops is calculated for the block containing the transactions.

You may have noticed the problem: for scripts like [P2PKH](https://bitcoin.org/en/developer-guide#term-p2pkh), OP\_CHECKSIG can appear in one block as a pubkey script but the actual time-consuming signature checking operation takes place when the signature script is evaluated in another block. In other words, it's possible to create a valid block today that requires performing more than 20,000 signature-checking operations but which has a sigops count of 0.

If we have to hard fork in megablocks, I think it possible that the opportunity will be taken to also change the sigops calculation formula---or to replace it with something different.

> **Comments:**
> **username_1**: Why would sig ops of an output without an input be counted at all? You only need to run the script when you have an input that spends the prevout, it seems silly that it was ever calculated this way, unless there is a different kind of CPU exhaustion attack that I am not thinking of?  
> **username_2**: No idea.  Satoshi [added the code](https://github.com/bitcoin/bitcoin/blame/8c9479c6bbbc38b897dc97de9d04e4d5a5a36730/main.h#L509-L517) that's [still used](https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L783-L795).  (Note Satoshi's contributions are credited on GitHub to the user saracen; the commit log says s_nakamoto.)  
> **username_0**: @username_2 BTW, you first linked to CTransaction::GetSigOpCount, but what's actually called by the code at the second link is [CScript::GetSigOpCount](https://github.com/bitcoin/bitcoin/blob/f914f1a746d7f91951c1da262a4a749dd3ebfa71/src/script/script.cpp#L166).  

---

