Published on: 2018-02-17T02:33:32+00:00
In a recent discussion on the bitcoin-dev forum, Johnson Lau highlighted the current limitations on block weight and sigops. Currently, the block weight limit is set at 4,000,000, with a sigop limit of 80,000. This means that each sigop cannot use more than 50 weight units. To address new script proposals, there is a suggestion to count the actual number of sigops during execution and ensure that the total number of executed sigops multiplied by 50 does not exceed the size of the input.Bitcoin Core has had a related policy rule in place for some time, where the weight of a transaction for mining purposes is determined by max(weight, lambda*sigops). However, lambda has been set lower than ideal due to limitations in checkmultisig. This policy replaced an earlier rule that rejected transactions with too many sigops per byte count, but it was found to block valid transactions. Moving forward, this framework may not be ideal as new operation proposals may require additional input but have relatively small computational costs, such as aggregation.In the early days of Bitcoin, Satoshi implemented sigops counting as a softfork to limit the number of signature operations in a block. However, this counting method was not contextual, resulting in an overestimation of the cost of multi-signature transactions and counting of sigops in unexecuted branches. As P2SH (Pay-to-Script-Hash) was introduced, sigop counting also encompassed the sigop redeemScript, improving the counting of OP_CHECKMULTISIG but making counting without the UTXO (Unspent Transaction Output) set impossible.Segwit (BIP141) addressed this issue by scaling the legacy sigop limit by 4x, with a new block limit of 80,000 sigops. Despite this improvement, implementing static sigop counting for second-generation script proposals like BIP114, BIP117, and taproot is challenging. However, it is still necessary to have a limit for more complex script functions in order to prevent unexpected Denial-of-Service (DoS) attacks.A proposal suggests that each sigop should not consume more than 50 weight units on average, with a per-input limit of (164 + input witness size) >= (actual_sigop * 50), where script validation is parallel. In cases where many signatures are aggregated, the 1:50 ratio may not be sufficient, and it could be reduced to 1:32 or lower to ensure that legitimate usage does not exceed the limit. This approach would allow relay nodes to determine if a transaction requires excessive CPU power by simply examining its size. If it does, the transaction would be considered invalid, and script execution could be terminated early.
Updated on: 2023-08-01T22:44:24.984635+00:00