Potential nasty corner case: Need to specify behavior of OP_OUTPUTBYTECODE

[cculianu]

In the context of a PATFO output appearing in a (non-standard, mined-only) txn, the following behavior should occur:

• Pre-activation, OP_OUTPUTBYTECODE should push the entire serialized blob for the PATFO output in question PREFIX_BYTE + token_data + locking_script. The 520b size limit should apply to this entire entity that is pushed.
• Post-activation: any outputs containing tokens push just the locking_script (no PREFIX_BYTE, no token data). The 520b size limit should apply to just this locking_script.

This fixes a corner case where a heterogenous network of some of "token aware" and some un-upgraded nodes co-existing on the same network don't fork away from each other.

Please add this to the spec somewhere..

Also.. for symmetry OP_UTXOBYTECODE should have similar semantics pre-activation, although PATFO inputs are unspendable anyway pre-activation so it doesn't matter so much what a node does there in practice as any introspection scripts that refer to PATFO inputs are going to be in a txn that is overall invalid.

[bitjson]

Thanks for finding this issue @cculianu and @joshmg! Definitely, I should have some additional test vectors shortly
to make this easier for future implementations to catch. Very glad it's already handled correctly in Verde and BCHN. 🚀