When the validity of scriptPubKey is checked?

Question

I have a couple of questions related to validation of script in transaction output (scriptPubKey).

I apologize for a little more text, but I tried to explain in detail what I don't understand.

Since all my confusion is related to the OP_RETURN opcode and OP_RETURN transaction, i.e. the following question and answer from Pieter Wuille all my questions are related to the validation of the scriptPubKey that contains this operator (OP_RETURN transaction), but I assume the same is true for all other output scripts.

Let's begin.

Based on what the Bitcoin wiki says that OP_RETURN marks the transaction as invalid and per Pieter's comment:

Transaction output scripts are only executed at the time they are attempted to be spent.

My first question is:

1. If the transaction output scripts are only executed at the time they are attempted to spent, does it mean that in scriptPubKey (transaction output script) we can write whatever we want and its validity will be only checked at the time of using? I mean if OP_RETURN makes the transaction invalid, and the validation is realized when creating the scriptPubKey (output), then the script with the given code can never be part of the blockchain

I think the answer to first question is false. The scriptPubKey is executed at the time its attempted to spent but its validity is checked at the time of creation of transaction that has that script in its transaction output. It's like a compiling and executing C program. Compiling means checking for syntax and semantic errors, or in case of scriptPubKey check, for example, if all correct opcodes are used, if script size is correct, if it is one of the standard transaction (if any of the above is not satisfied, the transaction containing this UTXO will be marked as invalid and discarded from the network). On the other hand, executing a C program can also cause the program to become invalid, say when dividing by 0. And that's exactly as with scriptPubKey and it's executing (as Pieter said) when attempting to spend it. If at the time of execution the script is marked as invalid (say it remains FALSE on the stack or an OP_RETURN operator is encountered), then the transaction that consumes the UTXO (not the one contains this UTXO) is marked as invalid. Therefore, although validation is performed when creating a transaction output, OP_RETURN is a valid code that passes validation, but executing a script that contains it invalidates the transaction. Since scriptPubKey is only executed when it is consumed, that transaction will be marked as invalid, and not the one that created scriptPubKey.

2. Is the above written true? Is the validity of the transaction output checked when making the transaction, and then while using the UTXO if something in the output script causes invalidity, the transaction that consumes that output will be marked as invalid?

Below is a question related to whether I understand validation correctly in the context of OP_RETURN.

When output containing [OP_RETURN] [DATA_PUSH] [data] is created, that UTXO will be successfully validated (since everything in it is OK) and recognized as standard OP_RETURN output that does not become part of the UTXO set. If everything other in transaction is okay, transaction is valid. However, if we were to try to use this UTXO, the transaction that consumes the given output will be marked as invalid, because it contains OP_RETURN. On the other hand, if we add something additional in front of OP_RETURN (some random opcode) in scriptPubKey, it will not pass validation since it's not recognized as a standard transaction, so a transaction that has this output would be invalidated

3. Did I understand correctly, that is, was the above written correctly?

4. Does everything previously written about validation actually apply to all other types of output (P2PK, P2PKH, P2WPKH, P2SH etc.). That is, validating on creation and then potentially marking an invalid transaction during execution (although with P2PKH this can only happen by combining a locking and unlocking script where the signature is not good, not like with an OP_RETURN transaction that UTXO itself marks an invalid transaction regardless to the unlock script)?

Answer 1

If the transaction output scripts are only executed at the time they are attempted to spent, does it mean that in scriptPubKey (transaction output script) we can write whatever we want and its validity will be only checked at the time of using?

Yes. Indeed, the scriptPubKey doesn't even need to be a valid script.

For example, take a look at transaction ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767. None of its outputs have a valid script as they all consist of push opcodes without pushing the expected amount of data. This makes these outputs forever unspendable, but because scriptPubKeys aren't checked before spending, transactions that create them are valid.

On the other hand, if we add something additional in front of OP_RETURN (some random opcode) in scriptPubKey, it will not pass validation since it's not recognized as a standard transaction, so a transaction that has this output would be invalidated

You might be confusing validity and standardness. There are only a handful standard output formats, one of which is OP_RETURN which consists of exactly one OP_RETURN opcode and then only push opcodes and data (up to 83 bytes by default). Adding other opcodes to the script would make it non-standard but not invalid, as we've already seen that scriptPubKeys aren't checked for validity.

Answer 2

Bitcoin Core will perform some lightweight checks in any incoming transactions and check whether they match a set of Relay Policy standards. If they do, then they broadcast the transaction to its peers and accept to mempool. However, policy checks aren't consensus, nor execute the transaction script. It mostly constrains resource usage and disallows some obscure OPs combination.

As of today, bitcoin core will match all outputs against some known transaction outputs: Bare Multisig, P2PK, Data Carrier (OP_RETURN), P2PKH, P2SH… and will only broadcast transactions matching those know templates. There are many explanations for that, like disincentivising creating transactions that would interfere with SF and because so obscure OPs aren't well tested. But by default, core calls any tx that is not a known template a non-standard tx and if you don't change anything, you can't get core to broadcast those. It doesn't do extensive validations, like validating the public keys because this is costly and can open some DDoS vectors.

This is not a validation itself. As noted, you only ever validate a script once it gets spent. Moreover, all those checks are for mempool transactions and don't apply to transactions that somehow get into a block. Miners can add transactions violating policy rules if they like.

Data Carrier transactions have a special treatment because they are "Provable unspendable", so you can remove them from your UTXO set.