<blockquote>
<p>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?</p>
</blockquote>
<p>Yes. Indeed, the scriptPubKey doesn't even need to be a valid script.</p>
<p>For example, take a look at transaction <a href="https://mempool.space/tx/ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767" rel="nofollow noreferrer">ebc9fa1196a59e192352d76c0f6e73167046b9d37b8302b6bb6968dfd279b767</a>. 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.</p>
<blockquote>
<p>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</p>
</blockquote>
<p>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.</p>

CC BY-SA 4.0
2023-08-01T17:20:22.370Z
Is there at least something checked within the scriptPubKey? I wrote in the question as examples to check if the correct opcodes are used or if the script size is correct. Does it at least check that the correct opcodes are being used or nothing at all?
dassd
CC BY-SA 4.0
2023-08-01T17:29:04.883Z
No, the scriptPubKey can be any byte vector (including the empty vector).
Vojtěch Strnad
CC BY-SA 4.0
2023-08-01T17:37:11.983Z
Thank you very much for your reply. So, you can write whatever you want in scriptPubKey and it is valid (not even checked?), but if it's a not-standard script (P2PK, P2PKH, OP_RETURN etc) when the nodes get it, they won't pass it to other peers so that such a transaction will not spread across the network (they only check if standard)? But if such a transaction (with non-standard output) is part of a block mined by a miner, all nodes will accept it because it is valid (they are not checking scriptPubKey). However, miners will not take into account such transactions. Did I understand correctly?
dassd
CC BY-SA 4.0
2023-08-01T18:06:57.663Z
That is correct, except perhaps for the last sentence. Miners don't necessarily run the default Bitcoin Core node policy and can accept non-standard transactions via other channels than the peer-to-peer network. But in general it's correct.
Vojtěch Strnad
CC BY-SA 4.0
2023-08-01T18:23:17.543Z
One way in which scriptPubKeys do affect validity is (a) through their size (which contributes to the block weight) and (b) surprisingly, sigops in scriptPubKeys are counted towards the 20000 sigops per block limit, despite only being executed at spending time.
Pieter Wuille
CC BY-SA 4.0
2023-08-01T18:24:34.430Z
I'm relatively new to Bitcoin (and blockchain in general) so I didn't know that. Let me check one more time. So I can write whatever I want in scriptPubKey (say, "filip") and it will not pass the STANDARDNESS CHECK (check for forwarding through the network) because it is not one of the standard transactions (P2PKH, P2SH, etc). However, if I directly give the miner this transaction, it will be accepted by all full nodes, because part of the VALIDITY CHECK is not checking the content of the output script? On the other hand, the scriptSig content and its execution is part of both types of checks?
dassd
CC BY-SA 4.0
2023-08-01T18:26:08.747Z
@Filip That's correct. Miners are allowed to put transactions in their blocks with arbitrary scriptPubKey byte arrays (as long as the resulting block doesn't violate any of the many other rules, which do include weight and sigops limits).
Pieter Wuille
CC BY-SA 4.0
2023-08-01T18:32:58.490Z
@PieterWuille Thanks Pieter, so the content of scriptPubKey is not part of the validity check, but (based on your comment) its size derived from its content is? So as part of the validity we only check its size and by that indirectly its content? Not sure exactly how sigops work yet (soon). Am I right?
dassd
CC BY-SA 4.0
2023-08-01T18:33:38.750Z
The scriptPubKey affects the size (weight) of the block literally just by being part of the block. Bigger scriptPubKey = bigger block.
Pieter Wuille
CC BY-SA 4.0
2023-08-01T18:35:33.900Z
@PieterWuille Yes, yes, and we'll just check that as part of validity check of scriptPubKey (I'm ignoring sigops for now).
dassd
CC BY-SA 4.0
2023-08-01T18:37:30.697Z
No, there is no specific validity check of scriptPubKeys. I'm just talking about the overall "is the block not too big" check that's done once for the block, as an example for how scriptPubKeys (in this case, their length) do have the ability to affect block validity.
Pieter Wuille
CC BY-SA 4.0
2023-08-01T18:44:42.003Z
@PieterWuille Oh, I didn't get it at first. So there is no validity check specifically for the size of the scriptPubKey or anything about it. But when the size of the block is checking during the validity check of the block, since the size of scriptPubKey affects it, scriptPubKey content (that is, its size) is indirectly part of the validity check. Is that what you want to say?
dassd
CC BY-SA 4.0
2023-08-01T18:47:50.040Z
@Filip Right, exactly. I just want to make it clear that "no specific check for validity of scriptPubKey" does not mean that the scriptPubKey's contents is irrelevant. As another (trivial) example, you already know that scriptPubKeys are covered by transaction signatures, so the wrong scriptPubKey can lead to a signature check failure.
Pieter Wuille
CC BY-SA 4.0
2023-08-01T19:02:01.400Z
@PieterWuille Yes, yes, got it, thanks. Just at the end. So: scriptPubKey content - standardness check only (forwarding check) since every content is valid (it's not even checked for validity); scriptSig content - standardness and validity check since not all content is valid ("filip" content of the scriptSig is invalid and will produce error when executing). By the way, "filip" content of scriptPubKey would be also invalid, but only when it's referenced by some input and executed (by itself it is valid). Right?
dassd
CC BY-SA 4.0
2023-08-01T19:05:25.963Z
@Filip Not every scriptPubKey content is valid (see examples above again, like weight, sigops, signature coverage, there are many more). It's just that there is no specific check for what scriptPubKeys are allowed in consensus (e.g. no checks that outlaw non-existing opcodes). And "filip" may well be valid as scriptSig for some scripts (just not for typical ones). There **are** indeed specific scriptPubKey checks (such as being too large, or containing invalid opcodes) that apply when the output it appears in gets spent.
Pieter Wuille
CC BY-SA 4.0
2023-08-01T19:16:23.820Z
@PieterWuille Yes, that's what I meant. I meant to say that there is no specific validity check of content of scriptPubKey (if we ignore block weight etc), for example "filip" would be fully accepted as valid (not standard). On the other hand, this is not true for scriptSig because now the content is checked (and executed) so "filip" is completely invalid because no part within "filip" is an opcode. Also, if we include a scriptPubKey containing "filip" that would also be invalid, because now that content is also checked (and executed). That's what I thought. Is it fine, I understand correctly?
dassd
CC BY-SA 4.0
2023-08-01T19:43:09.940Z
The ASCII encoding of "filip" could well be a script, though the f would be interpreted as OP_VERNOTIF, which will immediately mark the transaction as invalid. So indeed, it cannot occur in a valid transaction's scriptSig.
Pieter Wuille
CC BY-SA 4.0
2023-08-01T19:53:37.913Z
@PieterWuille Yes, and therefore not in scriptPubKey, but ONLY when we want the output with such a script to be referenced and consumed since its execution will make invalid the transaction using it. If we don't want to spend that UTXO, then everything is okay, since the content of scriptPubKey is not checked and every content is valid (ignoring block weight, sigops etc).
dassd
CC BY-SA 4.0
2023-08-01T20:07:02.033Z
Right, indeed, "filip" would be valid as a non-standard scriptPubKey, but won't be spendable.
Pieter Wuille
CC BY-SA 4.0
2023-08-01T20:08:42.220Z
@PieterWuille Thanks, Pieter. All the best!
dassd
CC BY-SA 4.0
2023-08-01T17:11:51.743Z
2023-08-01T20:36:39.790Z
2023-08-01T20:36:39.790Z
Vojtěch Strnad
<p>Bitcoin Core will perform some lightweight checks in any incoming transactions and check whether they match a set of <strong>Relay Policy</strong> 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.</p>
<p>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 <strong>non-standard</strong> 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.</p>
<p>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.</p>
<p>Data Carrier transactions have a special treatment because they are &quot;Provable unspendable&quot;, so you can remove them from your UTXO set.</p>

CC BY-SA 4.0
2023-08-01T17:06:11.510Z
First of all, thanks for your reply. Yes, I understand that when a non-standard transaction comes it will be discarded, it will not be forwarded to other nodes. But what if a standard transaction comes through? Let's say an OP_RETURN transaction? Does that validation then take place as I described under the first question? That is, the validation of the output is in the context of whether the size of the script is good, whether all opcodes are good, etc, while input validation is based on the execution of the script where during that execution the transaction may also be declared invalid.
dassd
CC BY-SA 4.0
2023-08-01T18:24:43.373Z
There is **no** requirement that all opcodes in a scriptPubKey are good. Literally any byte vector is allowed (but see my comment on the other answer).
Pieter Wuille
CC BY-SA 4.0
2023-08-01T16:56:20.803Z
2023-08-01T16:56:20.803Z
Davidson Souza
<p>I have a couple of questions related to validation of script in transaction output (scriptPubKey).</p>
<p><strong>I apologize for a little more text, but I tried to explain in detail what I don't understand.</strong></p>
<p>Since all my confusion is related to the OP_RETURN opcode and OP_RETURN transaction, i.e. <a href="https://bitcoin.stackexchange.com/questions/49303/op-return-marks-transaction-or-output-as-invalid">the following question</a> and <a href="https://bitcoin.stackexchange.com/a/49304">answer from <strong>Pieter Wuille</strong></a> 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.</p>
<p>Let's begin.</p>
<p>Based on what <a href="https://en.bitcoin.it/wiki/Script#Flow_control" rel="nofollow noreferrer">the Bitcoin wiki says</a> that OP_RETURN marks the transaction as invalid and per Pieter's comment:</p>
<blockquote>
<p>Transaction output scripts are only executed at the time they are
attempted to be spent.</p>
</blockquote>
<p>My first question is:</p>
<p><strong>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</strong></p>
<p>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, <strong>the transaction containing this UTXO</strong> 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 <strong>transaction that consumes the UTXO</strong> (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.</p>
<p><strong>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?</strong></p>
<p>Below is a question related to whether I understand validation correctly in the context of OP_RETURN.</p>
<p>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</p>
<p><strong>3. Did I understand correctly, that is, was the above written correctly?</strong></p>
<p><strong>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)?</strong></p>

<transactions><script><transaction-verification><validation><output>
When the validity of scriptPubKey is checked?
dassd
# When the validity of scriptPubKey is checked?

(Asked by: username_0 on 2023-08-01)

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](https://bitcoin.stackexchange.com/questions/49303/op-return-marks-transaction-or-output-as-invalid) and [answer from **username_2 username_2**](https://bitcoin.stackexchange.com/a/49304) 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](https://en.bitcoin.it/wiki/Script#Flow_control) that OP\_RETURN marks the transaction as invalid and per username_2'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 username_2 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)?**

**Tags:** transactions, script, transaction-verification, validation, output


---

## 2 answers

### Answer by username_1 on 2023-08-01. Score: 3 | Accepted answer

> 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](https://mempool.space/tx/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.

> **Comments:**
> **username_0**: Is there at least something checked within the scriptPubKey? I wrote in the question as examples to check if the correct opcodes are used or if the script size is correct. Does it at least check that the correct opcodes are being used or nothing at all?  
> **username_1**: No, the scriptPubKey can be any byte vector (including the empty vector).  
> **username_0**: Thank you very much for your reply. So, you can write whatever you want in scriptPubKey and it is valid (not even checked?), but if it's a not-standard script (P2PK, P2PKH, OP_RETURN etc) when the nodes get it, they won't pass it to other peers so that such a transaction will not spread across the network (they only check if standard)? But if such a transaction (with non-standard output) is part of a block mined by a miner, all nodes will accept it because it is valid (they are not checking scriptPubKey). However, miners will not take into account such transactions. Did I understand correctly?  
> **username_1**: That is correct, except perhaps for the last sentence. Miners don't necessarily run the default Bitcoin Core node policy and can accept non-standard transactions via other channels than the peer-to-peer network. But in general it's correct.  
> **username_2**: One way in which scriptPubKeys do affect validity is (a) through their size (which contributes to the block weight) and (b) surprisingly, sigops in scriptPubKeys are counted towards the 20000 sigops per block limit, despite only being executed at spending time.  
> **username_0**: I'm relatively new to Bitcoin (and blockchain in general) so I didn't know that. Let me check one more time. So I can write whatever I want in scriptPubKey (say, "filip") and it will not pass the STANDARDNESS CHECK (check for forwarding through the network) because it is not one of the standard transactions (P2PKH, P2SH, etc). However, if I directly give the miner this transaction, it will be accepted by all full nodes, because part of the VALIDITY CHECK is not checking the content of the output script? On the other hand, the scriptSig content and its execution is part of both types of checks?  
> **username_2**: @Filip That's correct. Miners are allowed to put transactions in their blocks with arbitrary scriptPubKey byte arrays (as long as the resulting block doesn't violate any of the many other rules, which do include weight and sigops limits).  
> **username_0**: @username_2 Thanks username_2, so the content of scriptPubKey is not part of the validity check, but (based on your comment) its size derived from its content is? So as part of the validity we only check its size and by that indirectly its content? Not sure exactly how sigops work yet (soon). Am I right?  
> **username_2**: The scriptPubKey affects the size (weight) of the block literally just by being part of the block. Bigger scriptPubKey = bigger block.  
> **username_0**: @username_2 Yes, yes, and we'll just check that as part of validity check of scriptPubKey (I'm ignoring sigops for now).  
> **username_2**: No, there is no specific validity check of scriptPubKeys. I'm just talking about the overall "is the block not too big" check that's done once for the block, as an example for how scriptPubKeys (in this case, their length) do have the ability to affect block validity.  
> **username_0**: @username_2 Oh, I didn't get it at first. So there is no validity check specifically for the size of the scriptPubKey or anything about it. But when the size of the block is checking during the validity check of the block, since the size of scriptPubKey affects it, scriptPubKey content (that is, its size) is indirectly part of the validity check. Is that what you want to say?  
> **username_2**: @Filip Right, exactly. I just want to make it clear that "no specific check for validity of scriptPubKey" does not mean that the scriptPubKey's contents is irrelevant. As another (trivial) example, you already know that scriptPubKeys are covered by transaction signatures, so the wrong scriptPubKey can lead to a signature check failure.  
> **username_0**: @username_2 Yes, yes, got it, thanks. Just at the end. So: scriptPubKey content - standardness check only (forwarding check) since every content is valid (it's not even checked for validity); scriptSig content - standardness and validity check since not all content is valid ("filip" content of the scriptSig is invalid and will produce error when executing). By the way, "filip" content of scriptPubKey would be also invalid, but only when it's referenced by some input and executed (by itself it is valid). Right?  
> **username_2**: @Filip Not every scriptPubKey content is valid (see examples above again, like weight, sigops, signature coverage, there are many more). It's just that there is no specific check for what scriptPubKeys are allowed in consensus (e.g. no checks that outlaw non-existing opcodes). And "filip" may well be valid as scriptSig for some scripts (just not for typical ones). There **are** indeed specific scriptPubKey checks (such as being too large, or containing invalid opcodes) that apply when the output it appears in gets spent.  
> **username_0**: @username_2 Yes, that's what I meant. I meant to say that there is no specific validity check of content of scriptPubKey (if we ignore block weight etc), for example "filip" would be fully accepted as valid (not standard). On the other hand, this is not true for scriptSig because now the content is checked (and executed) so "filip" is completely invalid because no part within "filip" is an opcode. Also, if we include a scriptPubKey containing "filip" that would also be invalid, because now that content is also checked (and executed). That's what I thought. Is it fine, I understand correctly?  
> **username_2**: The ASCII encoding of "filip" could well be a script, though the f would be interpreted as OP_VERNOTIF, which will immediately mark the transaction as invalid. So indeed, it cannot occur in a valid transaction's scriptSig.  
> **username_0**: @username_2 Yes, and therefore not in scriptPubKey, but ONLY when we want the output with such a script to be referenced and consumed since its execution will make invalid the transaction using it. If we don't want to spend that UTXO, then everything is okay, since the content of scriptPubKey is not checked and every content is valid (ignoring block weight, sigops etc).  
> **username_2**: Right, indeed, "filip" would be valid as a non-standard scriptPubKey, but won't be spendable.  
> **username_0**: @username_2 Thanks, username_2. All the best!  

---

### Answer by username_3 on 2023-08-01. Score: 0

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.

> **Comments:**
> **username_0**: First of all, thanks for your reply. Yes, I understand that when a non-standard transaction comes it will be discarded, it will not be forwarded to other nodes. But what if a standard transaction comes through? Let's say an OP_RETURN transaction? Does that validation then take place as I described under the first question? That is, the validation of the output is in the context of whether the size of the script is good, whether all opcodes are good, etc, while input validation is based on the execution of the script where during that execution the transaction may also be declared invalid.  
> **username_2**: There is **no** requirement that all opcodes in a scriptPubKey are good. Literally any byte vector is allowed (but see my comment on the other answer).  

---

