Return to Revisions

These are the scriptPubKey's that are standard, arranged in order of popularity:

1. P2PKH (Pay to public key hash)

    OP_DUP OP_HASH160 <20 bytes of public key hash> OP_EQUALVERIFY OP_CHECKSIG
   

2. P2SH (Pay to script hash)

    OP_HASH160 <20 bytes of script hash> OP_EQUAL
   

3. P2PK (Pay to public key)

This is now mostly unused, but there are still unspent outputs in the form:

    <33 or 65 bytes of public key> OP_CHECKSIG

4. m-of-n bare multisig

Also pretty rare.

    <m> [n <public key>s] <n> OP_CHECKMULTISIG

5. Data-carrying, output

Only one of these is allowed per transaction. These outputs can never be spent, so you probably don't need to detect them.

    OP_RETURN <less than 80 bytes of data>

Should I implement more sophisticated script parser which can detect "non-standard" scripts as well?

No. It's a waste of development time, when nobody uses transactions like that. (If they did, those transaction types would be added to the list of standard transactions. :))

It's also going to be very difficult to implement correctly. If you don't do it correctly, then you'll think you have coins when you really don't. For example, imagine someone sends you a transaction with a scriptPubKey like this:

OP_DUP OP_HASH160 <20 bytes of public key hash> OP_2DROP OP_CHECKSIG

Note that this is like a P2PKH output, except that OP_EQUALVERIFY has been replaced by OP_2DROP. That means that the script checks that the signature is correct, but doesn't check that it's signed by the right key.

That means that anybody can spend it, not just you. Correctly detecting edge cases like these make writing a program that can understand nonstandard outputs more trouble than it's worth.