<p>You might be thinking of <a href="https://b10c.me/observations/09-non-standard-transactions/" rel="nofollow noreferrer">valid yet non-standard</a> transactions. From the point of view of the node software:</p>
<p><a href="https://bitcoin.stackexchange.com/a/122859/34190">Standardness</a> is what type of transactions <em>should</em> be included.</p>
<p>Validity is what type of transactions <em>could</em> be included.</p>
<p>If a node sees a prospective transaction as non-standard it will not share it on the P2P network and will not include it in candidate blocks for mining, even if it is valid. However, if it sees non-standard yet valid transaction has been confirmed on the chain, it will accept it.</p>
<p>Bitcoin Core and and Bitcoin Knots have a slightly different point of view (policy) on standardness, but agree on validity. If nodes were to disagree on validity, there would likely be a fork.</p>
<blockquote>
<p>...how will it be backwards compatible?</p>
</blockquote>
<p>It might be worth looking at <a href="https://github.com/bitcoin/bitcoin/blob/98dd4e712efaa2b77cb168426756879c6405c3f4/src/script/interpreter.cpp#L1085C16-L1086C145" rel="nofollow noreferrer"><code>OP_CHECKSIGADD</code></a> for an example opcode only used in Tapscript.</p>
<pre class="lang-cpp prettyprint-override"><code>case OP_CHECKSIGADD:
    {
        // OP_CHECKSIGADD is only available in Tapscript
        if (sigversion == SigVersion::BASE || sigversion == SigVersion::WITNESS_V0) return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
</code></pre>
<blockquote>
<p>But if it is a policy, op_cat can appear today with a help of a miner?</p>
</blockquote>
<p>No, the script would be invalid. Such a transaction, and its block, would be rejected as invalid by all nodes running a Bitcoin Core version, or derivation, released since <a href="https://github.com/bitcoin/bitcoin/blob/98dd4e712efaa2b77cb168426756879c6405c3f4/src/script/interpreter.cpp#L456" rel="nofollow noreferrer">OP_CAT was removed</a> (i.e. ~all of them).</p>

CC BY-SA 4.0
2024-05-10T12:25:47.307Z
Thanks for the answer, how are they planning on adding the op_cat then, if it will be rejected by for example core 27.0?
user151596
CC BY-SA 4.0
2024-05-10T13:01:17.653Z
I found out, they are adding it as a new opcode in tapscript, not reenabling the old one
user151596
CC BY-SA 4.0
2024-05-10T08:58:35.640Z
2024-05-10T08:58:35.640Z
Lee
<p>With all the recent developments of the spammers and those who want to filter them. I have a few things I don't get. They mention the bug that wasn't fixed (CVE-2023-50428). As I understand, this &quot;bug&quot; is that Bitcoin Core developers did not implement a filter for the jpegs on the policy side of things after the taproot has merged, and if they would, like Bitcoin Knots did, it could still get into the block with a help of a miner because it still would be within the consensus. That's the first one. Another one is about op_cat and other covenant proposals. For example the bip 420 is for the reintroduction of op_cat. As Satoshi removed it, is it forbidden on the consensus side or on the policy side. If it was removed from the consensus, if it will be merged, how will it be backwards compatible? But if it is a policy, op_cat can appear today with a help of a miner?</p>
<p>Thanks</p>

CC BY-SA 4.0
2024-05-10T09:02:23.147Z
there is too many questions in one there. Could you try and ask each question separately? Mind subjective questions aren't a good fit for this site so try to phrase it so it's more focused on some objective technical aspects of it.
Antoine Poinsot
<bitcoin-core><consensus><ordinals><bip347-op-cat>
Consensus Question
user151596
# Consensus Question

(Asked by: username_0 on 2024-05-10)

With all the recent developments of the spammers and those who want to filter them. I have a few things I don't get. They mention the bug that wasn't fixed (CVE-2023-50428). As I understand, this "bug" is that Bitcoin Core developers did not implement a filter for the jpegs on the policy side of things after the taproot has merged, and if they would, like Bitcoin Knots did, it could still get into the block with a help of a miner because it still would be within the consensus. That's the first one. Another one is about op\_cat and other covenant proposals. For example the bip 420 is for the reintroduction of op\_cat. As Satoshi removed it, is it forbidden on the consensus side or on the policy side. If it was removed from the consensus, if it will be merged, how will it be backwards compatible? But if it is a policy, op\_cat can appear today with a help of a miner?

Thanks

**Tags:** bitcoin-core, consensus, ordinals, bip347-op-cat

> **Comments:**
> **username_1**: there is too many questions in one there. Could you try and ask each question separately? Mind subjective questions aren't a good fit for this site so try to phrase it so it's more focused on some objective technical aspects of it.  

---

## 1 answers

### Answer by username_2 on 2024-05-10. Score: 0

You might be thinking of [valid yet non-standard](https://b10c.me/observations/09-non-standard-transactions/) transactions. From the point of view of the node software:

[Standardness](https://bitcoin.stackexchange.com/a/122859/34190) is what type of transactions *should* be included.

Validity is what type of transactions *could* be included.

If a node sees a prospective transaction as non-standard it will not share it on the P2P network and will not include it in candidate blocks for mining, even if it is valid. However, if it sees non-standard yet valid transaction has been confirmed on the chain, it will accept it.

Bitcoin Core and and Bitcoin Knots have a slightly different point of view (policy) on standardness, but agree on validity. If nodes were to disagree on validity, there would likely be a fork.

> ...how will it be backwards compatible?

It might be worth looking at [`OP_CHECKSIGADD`](https://github.com/bitcoin/bitcoin/blob/98dd4e712efaa2b77cb168426756879c6405c3f4/src/script/interpreter.cpp#L1085C16-L1086C145) for an example opcode only used in Tapscript.

```cpp
case OP_CHECKSIGADD:
    {
        // OP_CHECKSIGADD is only available in Tapscript
        if (sigversion == SigVersion::BASE || sigversion == SigVersion::WITNESS_V0) return set_error(serror, SCRIPT_ERR_BAD_OPCODE);

```

> But if it is a policy, op\_cat can appear today with a help of a miner?

No, the script would be invalid. Such a transaction, and its block, would be rejected as invalid by all nodes running a Bitcoin Core version, or derivation, released since [OP\_CAT was removed](https://github.com/bitcoin/bitcoin/blob/98dd4e712efaa2b77cb168426756879c6405c3f4/src/script/interpreter.cpp#L456) (i.e. ~all of them).

> **Comments:**
> **username_0**: Thanks for the answer, how are they planning on adding the op_cat then, if it will be rejected by for example core 27.0?  
> **username_0**: I found out, they are adding it as a new opcode in tapscript, not reenabling the old one  

---

