Is there any part of the Bitcoin protocol that establishes a limit on the maximum number of op_codes in a script?
Playing in the testnet I have recently hit the limit of script operations for the bitcoin core client. After digging a bit I found in line 276 of
https://github.com/bitcoin/bitcoin/blob/ce56f5621a94dcc2159ebe57e43da727eab18e6c/src/script/interpreter.cpp if (opcode > OP_16 && ++nOpCount > 201)
return set_error(serror, SCRIPT_ERR_OP_COUNT);
So for non-standard transactions, there is a limit to 201 operations beside pushing a number from 0 to 16 to the stack (and similar limits inside other types of transactions).
I cannot find any discussion or explanation on why exactly 201 operations. The limit to multisign signatures to avoid attacks is more or less clear to me (and I have found a clear-cut limit
https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#520byte_limitation_on_serialized_script_size), but for lightweight operations (OP_ADD and the like) I cannot find any explanation on the limit and the exact 201 value.
More on that:
I tested two transactions:
94285d9867b0c008b03467164d89451e732fe8243890dd04164633c5e403777d with a long redeem condition and
4114ff60040c60158e21bba9391af3798af49a56c9f918596b8419622bfa8fdb that should fulfill it.
If I try to broadcast the second transaction with bitcoin-cli I get the message:
error: {"code":-26,"message":"16: mandatory-script-verify-flag-failed (Operation limit exceeded)"}
However, I was able to push it to the mempool of a Ruby client:
http://test.webbtc.com/mempool_tx/4114ff60040c60158e21bba9391af3798af49a56c9f918596b8419622bfa8fdbIt seems stuck there as no miners will accept it. Could this create a fork if the transaction is added to a block by a Ruby miner? I guess this is unlikely as you would need a large mining power on the alternative client. In that case, would my first transaction really be irredeemable in the current network or get stuck in an orphaned block?
Am I missing anything?
