MatchCuctomColoredScript() should much any valid script that has OP_COLOR

[rantan]

like

CScript() << ParseHex("c11863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262") << OP_1 << OP_DROP << OP_COLOR << OP_9 << OP_ADD << OP_11 << OP_EQUAL;

If the MatchCustomColoredScript() gets this script, it should return true but now is false.

The current implementation checks whether the script matches with the pattern 0x21 <33bytes> OP_COLOR. However, this way can't recognize cases that having opcodes that have no side effect, between <33bytes> and OP_COLOR.

[rantan]

Txs that have this kind of custom script are not acceptable in mempool.
So no one can broadcast txs that include this kind of script.

[Naviabheeman]

To handle custom scripts like this can we change the current implementation of "standard" checks in Tapyrus to a stack based one:

Assuming that script flags SCRIPT_VERIFY_SIGPUSHONLY and SCRIPT_VERIFY_CLEANSTACK (now in tapyrus only SCRIPT_VERIFY_SIGPUSHONLY  is set as standard) are set we can assume that script sig stack has only data not operators.

• We can evaluate scriptpubkey on the stack in terms of push and pop stack operations only. The script evaluation will not be the same as verifyscript but will count the stack change after every operator. If at the end of the script the stack is empty as expected then the script can be assumed to be standard. Otherwise it can be non standard.

• IF SIGPUSHONLY  and CLEANSTACK are not set we will not use this method. But use solver as it is now.

 
This can be an entirely new set of classes for script changes. In the future we enhance it and make it a separate library for script verification.
 
 @azuchi, @rantan and @Yamaguchi what do you think?

[azuchi]

At this point, I think the standard rule is to only cover CP2PKH and CP2SH.