<blockquote>
<p>So, is the given operator disabled in Bitcoin</p>
</blockquote>
<p><a href="https://github.com/bitcoin/bitcoin/blob/v25.0/src/script/interpreter.cpp#L1047" rel="nofollow noreferrer">No</a>.</p>
<blockquote>
<p>can it still be used?</p>
</blockquote>
<p>Yes. It is still supported in bare scripts (but non-standard there), in P2SH redeemscripts, and care was taken to keep supporting it in <a href="https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki" rel="nofollow noreferrer">segwit</a> and <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="nofollow noreferrer">taproot script</a> even (though the functionality changed somewhat in the latter). While it's unclear why the opcode existed in the first place (the best theory I've seen is to support <a href="https://bitcointalk.org/index.php?topic=255145.msg2773654#msg2773654" rel="nofollow noreferrer">delegation</a>, though that broke when the scriptSig and scriptPubKey execution split was introduced), it's also not harmful to have it, and in practice it <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-March/000455.html" rel="nofollow noreferrer">allows</a> creating a script that needs signatures that can only be used in some of its execution branches but not all.</p>
<blockquote>
<p>Signing is a critical part, so I'm wondering if there might be some weakness in the system when using this operator</p>
</blockquote>
<p>The existence of OP_CODESEPARATOR in pre-segwit scripts does worsen the quadratic hashing problem those scripts exhibit, by permitting many more distinct signatures over the same data that need separate hashing. It has <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016714.html" rel="nofollow noreferrer">been proposed</a> to remove that feature (only for pre-segwit) for that reason, though that idea seems abandoned at this point.</p>
<p>Note that that is a DoS concern for validation, and doesn't affect the security of individual signers. Wallets can always actively choose to use patently unsafe constructions (e.g. give out an address corresponding to an <code>OP_TRUE</code>). Generally the goal of script design isn't to rule out unsafe behavior, only to avoid footguns or incentivizing unsafe or non-private behavior. OP_CODESEPARATOR doesn't seem to cause these (probably because its use is too niche anyway), so while it's unlikely that such a feature would be <em>added</em> today, there is little reason to go through the tremendous effort of developing and building support for a consensus change to remove it just because its use is unclear.</p>

CC BY-SA 4.0
2023-09-30T10:41:43.577Z
Thanks Pieter, all the best!
dassd
CC BY-SA 4.0
2023-09-29T17:48:37.537Z
2023-09-29T18:11:54.047Z
2023-09-29T18:11:54.047Z
Pieter Wuille
<p><code>OP_CODESEPARATOR</code> is used in the Bitcoin script language to mark the beginning of signature-checked data. However, the given operator never found its real practical use case. So, is the given operator disabled in Bitcoin or can it still be used? If it is disabled, has any form of attack been detected that can be implemented using the given operator? Signing is a critical part, so I'm wondering if there might be some weakness in the system when using this operator, or is it disabled (if it is disabled) just because no one uses it?</p>

<script><attack><opcodes><signature-operations>
Is OP_CODESEPARATOR disabled in Bitcoin and if so why?
dassd
# Is OP_CODESEPARATOR disabled in Bitcoin and if so why?

(Asked by: username_0 on 2023-09-29)

`OP_CODESEPARATOR` is used in the Bitcoin script language to mark the beginning of signature-checked data. However, the given operator never found its real practical use case. So, is the given operator disabled in Bitcoin or can it still be used? If it is disabled, has any form of attack been detected that can be implemented using the given operator? Signing is a critical part, so I'm wondering if there might be some weakness in the system when using this operator, or is it disabled (if it is disabled) just because no one uses it?

**Tags:** script, attack, opcodes, signature-operations


---

## 1 answers

### Answer by username_1 on 2023-09-29. Score: 2 | Accepted answer

> So, is the given operator disabled in Bitcoin

[No](https://github.com/bitcoin/bitcoin/blob/v25.0/src/script/interpreter.cpp#L1047).

> can it still be used?

Yes. It is still supported in bare scripts (but non-standard there), in P2SH redeemscripts, and care was taken to keep supporting it in [segwit](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki) and [taproot script](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) even (though the functionality changed somewhat in the latter). While it's unclear why the opcode existed in the first place (the best theory I've seen is to support [delegation](https://bitcointalk.org/index.php?topic=255145.msg2773654#msg2773654), though that broke when the scriptSig and scriptPubKey execution split was introduced), it's also not harmful to have it, and in practice it [allows](https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-March/000455.html) creating a script that needs signatures that can only be used in some of its execution branches but not all.

> Signing is a critical part, so I'm wondering if there might be some weakness in the system when using this operator

The existence of OP\_CODESEPARATOR in pre-segwit scripts does worsen the quadratic hashing problem those scripts exhibit, by permitting many more distinct signatures over the same data that need separate hashing. It has [been proposed](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016714.html) to remove that feature (only for pre-segwit) for that reason, though that idea seems abandoned at this point.

Note that that is a DoS concern for validation, and doesn't affect the security of individual signers. Wallets can always actively choose to use patently unsafe constructions (e.g. give out an address corresponding to an `OP_TRUE`). Generally the goal of script design isn't to rule out unsafe behavior, only to avoid footguns or incentivizing unsafe or non-private behavior. OP\_CODESEPARATOR doesn't seem to cause these (probably because its use is too niche anyway), so while it's unlikely that such a feature would be *added* today, there is little reason to go through the tremendous effort of developing and building support for a consensus change to remove it just because its use is unclear.

> **Comments:**
> **username_0**: Thanks username_1, all the best!  

---

