As transaction size, the number of signature checks per transaction can affect client performance and the inclusion of many O_CHECKSIG opcodes could be used as a tool for denial-of-service attacks.

I found in CTransaction::AcceptToMemoryPool() the following check:

// Rather not work on nonstandard transactions if (GetSigOpCount() > 2 || ::GetSerializeSize(*this, SER_NETWORK) < 100) return error("AcceptToMemoryPool() : nonstandard transaction");

Then I suppose the OP_CHECKSIG limit is 2, which is fine for security but this limit prevents users from using the advanced contracts Bitcoin is suppose to allow.

Also there is the limit imposed by MAX_BLOCK_SIGOPS, but the limit applies to whole blocks, and only indirectly limit the sigops of a single transaction.


The error for nonstandard transaction is simply because they are not yet supported by mainline client. Remember as writing Bitcoin is only version 0.4 so significat portions of the protocol have not been implemented yet.

You will notice the error being thrown is "non standard transaction" which is indicating the client doesn't have support for creating or validating non-standard transactions.

Standard transactions are those with scriptPubKey of:

  • OP_CHECKSIG - transfer to IP Address OP_DUP OP_HASH160
  • OP_EQUALVERIFY OP_CHECKSIG - transfer to Bitcoin Address (hash of public key)

The only other transaction type supported is generation transaction which doesn't have a scriptPubKey to identify it. It is easily identified because every valid block must always have one and only one coinbase transaction.

Contracts are non-standard transactions and not supported by the client yet. The code snippet is simply to prevent client from attempting to process, broacast or validate non-standard transactions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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