You is perhaps pondering of legitimate but non-standard transactions. From the viewpoint of the node software program:
Standardness is what sort of transactions ought to be included.
Validity is what sort of transactions may be included.
If a node sees a potential transaction as non-standard it is not going to share it on the P2P community and won’t embrace it in candidate blocks for mining, even whether it is legitimate. Nevertheless, 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 viewpoint (coverage) on standardness, however agree on validity. If nodes had been to disagree on validity, there would possible be a fork.
…how will or not it’s backwards suitable?
It is perhaps price OP_CHECKSIGADD for an instance opcode solely utilized in Tapscript.
case OP_CHECKSIGADD:
{
// OP_CHECKSIGADD is just obtainable 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 in the present day with a assist of a miner?
No, the script could be invalid. Such a transaction, and its block, could 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).
