If block sizes go up, won't sigop limits have to change too?

Gavin Andresen, one of the core developers, has discussed increasing the block size to 16.7 MB (and doubling that every two years).

The maximum number of signature operations per block is currently set to 20000:

[...] 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?

Nick ODell

Posted 2015-01-23T07:00:21.937

Reputation: 26 536

Answers

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

morsecoder

Posted 2015-01-23T07:00:21.937

Reputation: 12 624

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, 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.

David A. Harding

Posted 2015-01-23T07:00:21.937

Reputation: 10 154

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 – 2015-01-23T14:46:37.760

No idea. Satoshi added the code that's still used. (Note Satoshi's contributions are credited on GitHub to the user saracen; the commit log says s_nakamoto.)

– David A. Harding – 2015-01-23T15:09:24.597

@DavidA.Harding BTW, you first linked to CTransaction::GetSigOpCount, but what's actually called by the code at the second link is CScript::GetSigOpCount.

– Nick ODell – 2015-01-24T01:38:35.480