2

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?

Improve this question
2
  • Fifty seems like an incredibly large number for a cap. I think even 12 or 20 would be reasonable.
    – m1xolyd1an
    Jun 3, 2017 at 4:12
  • 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
    Nov 1, 2017 at 15:31

1 Answer 1

Reset to default
1

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.