<p>The main concern with sigops is the quadratic behavior of the pre-segwit signature hash.  I believe specially constructed transactions with lots of OP_CHECKSIGS but few inputs would be similarly bad as transaction with many inputs.</p>

<p>Having additional limits also makes life a little harder for anyone working with the system; e.g. you have to be under 100k, AND under 50 inputs.</p>

<p>Ultimately the best solution is to avoid quadratic behavior like the new signature hashing in Bitcoin did.</p>

CC BY-SA 4.0
2018-07-23T12:39:28.497Z
2018-07-23T12:39:28.497Z
G. Maxwell
<p>One of the issues of increasing the blocksize is the possibility of creating attackblocks which would take significantly longer to parse than the common block. The mechanism to do so is by creating a transaction that fills the complete block exploiting the quadratic cost of verifying input scripts.</p>

<p>Bitcoin Classic proposed to limit the number of sigops per block. It seems to me that limiting the number of inputs to be used in one transaction would incentivize reduction of a wallet's UTXO footprint.</p>

<p>Has limiting the number of inputs been discussed as a potential solution? What would be the upsides and downsides of such a change?</p>

CC BY-SA 3.0
2017-06-03T04:12:27.867Z
Fifty seems like an incredibly large number for a cap. I think even 12 or 20 would be reasonable.
m1xolyd1an
CC BY-SA 3.0
2017-11-01T15:31:06.387Z
Bitcoin right now seems to resemble a store of value rather than cash, and most people arent spending small amounts every day; but if they do at some point, being able to retrieve many small UTXOs would be a requirement for making a single large transaction.
Scalextrix
<block><consensus><transaction-input>
What would be the implications of limiting Bitcoin transactions to fifty inputs?
Murch
# What would be the implications of limiting Bitcoin transactions to fifty inputs?

(Asked by: username_0 on 2017-06-02)

One of the issues of increasing the blocksize is the possibility of creating attackblocks which would take significantly longer to parse than the common block. The mechanism to do so is by creating a transaction that fills the complete block exploiting the quadratic cost of verifying input scripts.

Bitcoin Classic proposed to limit the number of sigops per block. It seems to me that limiting the number of inputs to be used in one transaction would incentivize reduction of a wallet's UTXO footprint.

Has limiting the number of inputs been discussed as a potential solution? What would be the upsides and downsides of such a change?

**Tags:** block, consensus, transaction-input

> **Comments:**
> **username_1**: Fifty seems like an incredibly large number for a cap. I think even 12 or 20 would be reasonable.  
> **username_2**: Bitcoin right now seems to resemble a store of value rather than cash, and most people arent spending small amounts every day; but if they do at some point, being able to retrieve many small UTXOs would be a requirement for making a single large transaction.  

---

## 1 answers

### Answer by username_3 on 2018-07-23. Score: 1 | Accepted answer

The main concern with sigops is the quadratic behavior of the pre-segwit signature hash. I believe specially constructed transactions with lots of OP\_CHECKSIGS but few inputs would be similarly bad as transaction with many inputs.

Having additional limits also makes life a little harder for anyone working with the system; e.g. you have to be under 100k, AND under 50 inputs.

Ultimately the best solution is to avoid quadratic behavior like the new signature hashing in Bitcoin did.


---

