You may be considering of legitimate but non-standard transactions. From the perspective of the node software program:
Standardness is what kind of transactions ought to be included.
Validity is what kind of transactions may be included.
If a node sees a potential transaction as non-standard it won’t share it on the P2P community and won’t embody it in candidate blocks for mining, even whether it is legitimate. Nonetheless, if it sees non-standard but legitimate transaction has been confirmed on the chain, it is going to settle for it.
Bitcoin Core and and Bitcoin Knots have a barely completely different perspective (coverage) on standardness, however agree on validity. If nodes have been to disagree on validity, there would possible be a fork.
…how will or not it’s backwards suitable?
It may be value taking a look at OP_CHECKSIGADD for an instance opcode solely utilized in Tapscript.
case OP_CHECKSIGADD:
{
// OP_CHECKSIGADD is barely accessible in Tapscript
if (sigversion == SigVersion::BASE || sigversion == SigVersion::WITNESS_V0) return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
But when it’s a coverage, op_cat can seem right this moment with a assist of a miner?
No, the script can be invalid. Such a transaction, and its block, can be rejected as invalid by all nodes working a Bitcoin Core model, or derivation, launched since OP_CAT was eliminated (i.e. ~all of them).
