# Great Consensus Cleanup Revival

**URL:** <https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710>\
**Category:** Protocol Design\
**Created:** [March 24, 2024, 5:29pm UTC](https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710 "2024-03-24T17:29:42Z")\
**Posts on this page:** 1\
**Showing post:** 67

<div class="post-metadata">

**Author:** ![harding](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/harding/32/925_2.png) [@harding](https://delvingbitcoin.org/u/harding)\
**Post date:** [February 5, 2025, 1:39pm UTC](https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/67 "2025-02-05T13:39:47Z")

</div>

> [@AntoineP](#):
>
> i believe the best way forward is to introduce a 2’500 per-transaction limit on the number of legacy (both bare and P2SH) input sigops.

In this accounting, how many sigops will `OP_CHECKMULTISIG` (CMS) count for? IIRC, current accounting for bare scripts (which is only applied to output scripts) counts each CMS as 20 sigops, but accounting for P2SH redeem scripts makes the sigops equal to CMS parameter for number of pubkeys to check (e.g. `2 <key> <key> <key> 3 OP_CMS` counts as 3 sigops).

Also, to be clear, am I correct assume the 2,500 input limit will apply to CHECK\*SIG operations specified in a bare prevout script? E.g., spending a P2PK output will count 1 sigop towards the transaction limit.

---

_[View the full topic](https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710)._