<p>OP_CHECKSIGADD is only defined for SegWit v1 (Taproot). A pre SegWit v1 node that doesn't recognize Taproot rules will treat all SegWit v1 outputs as &quot;anyone can spend&quot; regardless of whether it has a OP_CHECKSIGADD opcode in the script or not. (Of course it doesn't know about the OP_CHECKSIGADD rules). It is only doing partial verification on the transactions in a block and accepting any SegWit v1 spends as valid. Other nodes that do recognize SegWit v1 rules will do full verification of all transactions in the block and hence ultimately the pre SegWit v1 node will still follow the same chain.</p>
<p>In short the SegWit version is given precedence over the presence of an undefined opcode. An undefined SegWit version is &quot;anyone can spend&quot;.</p>

CC BY-SA 4.0
2024-04-26T12:08:05.590Z
Thanks, my understanding is that the `0x6a` opcode must only occur in the witness field of a transaction. If it was in the scriptSig or scriptPubKey field then all nodes would reject it.
Lee
CC BY-SA 4.0
2024-04-26T14:07:22.560Z
@Lee When a pre-taproot node sees a taproot spend, they do not even *get* to seeing/interpreting any opcodes. They just see it as an output of an unknown type, and say "ok, no rules apply, all good". From their perspective, the spending of such an output does *not involve any script at all*.
Pieter Wuille
CC BY-SA 4.0
2024-04-26T10:46:34.140Z
2024-04-26T10:51:54.933Z
2024-04-26T10:51:54.933Z
Michael Folkson
<p>Tapscript can only appear in leaf scripts. Leaf scripts can only appear in the witness stack of a P2TR script path spend. Pre-segwit nodes don’t see witness data. Ergo, a pre-segwit node will never encounter an <code>OP_CHECKSIGADD</code>.</p>

CC BY-SA 4.0
2024-04-26T21:49:31.647Z
Oh, in my comment on the other answer I assumed OP was asking about pre-taproot nodes. But indeed, pre-segwit nodes won't see the script at all.
Pieter Wuille
CC BY-SA 4.0
2024-04-27T07:16:58.117Z
@PieterWuille And if one did try to include a tx with non-witness script with an 0x6a opcode in it; it would fail on pre-Segwit/pre-Taproot as undefined, and on post Taproot as it detects that it's not a P2TR.
Lee
CC BY-SA 4.0
2024-04-26T17:56:46.513Z
2024-04-26T23:42:09.900Z
2024-04-26T23:42:09.900Z
Murch
<p>When pre-Segwit nodes encounter blocks with Segwit transactions, they'll see them as &quot;spent anyone can spend&quot; transactions and so can validate them and move on to the next block.</p>
<p>However, when they encounter a transaction with the opcode <code>0x6a</code> (Taproot only <code>OP_CHECKSIGADD</code>) <a href="https://bitcoin.stackexchange.com/a/122794/34190">they'd see it as an undefined opcode</a> and thus see the transaction and its block as invalid. They would then fork or become stranded.</p>
<p>After reading <a href="https://bitcoin.stackexchange.com/a/115705/34190">this</a>, though, it seems there is some way by which the old nodes handle/avoid <code>OP_CHECKSIGADD</code>.</p>
<p><strong>What is the mechanism by which the old nodes handle the <code>0x6a</code>/<code>OP_CHECKSIGADD</code> opcode or are able to see these transactions as a &quot;spent anyone can spend&quot;?</strong></p>

<transactions><segregated-witness><multi-signature><taproot><soft-fork>
How do pre-Segwit nodes interpret transactions containing Taproot OP_CHECKSIGADD?
Lee
# How do pre-Segwit nodes interpret transactions containing Taproot OP_CHECKSIGADD?

(Asked by: username_0 on 2024-04-26)

When pre-Segwit nodes encounter blocks with Segwit transactions, they'll see them as "spent anyone can spend" transactions and so can validate them and move on to the next block.

However, when they encounter a transaction with the opcode `0x6a` (Taproot only `OP_CHECKSIGADD`) [they'd see it as an undefined opcode](https://bitcoin.stackexchange.com/a/122794/34190) and thus see the transaction and its block as invalid. They would then fork or become stranded.

After reading [this](https://bitcoin.stackexchange.com/a/115705/34190), though, it seems there is some way by which the old nodes handle/avoid `OP_CHECKSIGADD`.

**What is the mechanism by which the old nodes handle the `0x6a`/`OP_CHECKSIGADD` opcode or are able to see these transactions as a "spent anyone can spend"?**

**Tags:** transactions, segregated-witness, multi-signature, taproot, soft-fork


---

## 2 answers

### Answer by username_3 on 2024-04-26. Score: 3 | Accepted answer

Tapscript can only appear in leaf scripts. Leaf scripts can only appear in the witness stack of a P2TR script path spend. Pre-segwit nodes don’t see witness data. Ergo, a pre-segwit node will never encounter an `OP_CHECKSIGADD`.

> **Comments:**
> **username_2**: Oh, in my comment on the other answer I assumed OP was asking about pre-taproot nodes. But indeed, pre-segwit nodes won't see the script at all.  
> **username_0**: @PieterWuille And if one did try to include a tx with non-witness script with an 0x6a opcode in it; it would fail on pre-Segwit/pre-Taproot as undefined, and on post Taproot as it detects that it's not a P2TR.  

---

### Answer by username_1 on 2024-04-26. Score: 2

OP\_CHECKSIGADD is only defined for SegWit v1 (Taproot). A pre SegWit v1 node that doesn't recognize Taproot rules will treat all SegWit v1 outputs as "anyone can spend" regardless of whether it has a OP\_CHECKSIGADD opcode in the script or not. (Of course it doesn't know about the OP\_CHECKSIGADD rules). It is only doing partial verification on the transactions in a block and accepting any SegWit v1 spends as valid. Other nodes that do recognize SegWit v1 rules will do full verification of all transactions in the block and hence ultimately the pre SegWit v1 node will still follow the same chain.

In short the SegWit version is given precedence over the presence of an undefined opcode. An undefined SegWit version is "anyone can spend".

> **Comments:**
> **username_0**: Thanks, my understanding is that the `0x6a` opcode must only occur in the witness field of a transaction. If it was in the scriptSig or scriptPubKey field then all nodes would reject it.  
> **username_2**: @username_0 When a pre-taproot node sees a taproot spend, they do not even *get* to seeing/interpreting any opcodes. They just see it as an output of an unknown type, and say "ok, no rules apply, all good". From their perspective, the spending of such an output does *not involve any script at all*.  

---

