# Deploying new taproot leaf versions

**URL:** <https://delvingbitcoin.org/t/deploying-new-taproot-leaf-versions/406>\
**Category:** Protocol Design\
**Created:** [January 12, 2024, 4:08pm UTC](https://delvingbitcoin.org/t/deploying-new-taproot-leaf-versions/406 "2024-01-12T16:08:37Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Chris\_Stewart\_5](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/chris_stewart_5/32/296_2.png) [@Chris\_Stewart\_5](https://delvingbitcoin.org/u/Chris_Stewart_5)\
**Post date:** [January 12, 2024, 4:08pm UTC](https://delvingbitcoin.org/t/deploying-new-taproot-leaf-versions/406/1 "2024-01-12T16:08:37Z")

</div>

Hi all,

[I currently have another consensus proposal to add 64bit arithmetic op codes to the Script Interpreter](https://delvingbitcoin.org/t/64-bit-arithmetic-soft-fork/397/18). It has been suggested that an optimal way to deploy this feature is with a new taproot leaf version.

I have been unable to find any examples in draft consensus PRs on github of deploying _new_ leaf versions (please link me if they exist!). This post is intended to talk about what different leaf versions implemented in the interpreter would look like.

[From BIP341](https://github.com/bitcoin/bips/blob/deae64bfd31f6938253c05392aa355bf6d7e7605/bip-0341.mediawiki#cite_note-7)

> **[^](https://github.com/bitcoin/bips/blob/deae64bfd31f6938253c05392aa355bf6d7e7605/bip-0341.mediawiki#cite_ref-7-0)**  **What constraints are there on the leaf version?** First, the leaf version cannot be odd as _c[0] & 0xfe_ will always be even, and cannot be _0x50_ as that would result in ambiguity with the annex. In addition, in order to support some forms of static analysis that rely on being able to identify script spends without access to the output being spent, it is recommended to avoid using any leaf versions that would conflict with a valid first byte of either a valid P2WPKH pubkey or a valid P2WSH script (that is, both _v_ and _v | 1_ should be an undefined, invalid or disabled opcode or an opcode that is not valid as the first opcode). The values that comply to this rule are the 32 even values between _0xc0_ and _0xfe_ and also _0x66_, _0x7e_, _0x80_, _0x84_, _0x96_, _0x98_, _0xba_, _0xbc_, _0xbe_. Note also that this constraint implies that leaf versions should be shared amongst different witness versions, as knowing the witness version requires access to the output being spent.

Lets arbitrarily choose `0x66` as our leaf version.

My understanding it is capable to alter the _interpretation of op codes_ in `interpreter.cpp` based on what the leaf version is.

Here is my toy example. I decided to disable OP\_CHECKSIGADD for leaf version `0x66` in my code. Setting aside the functionality of this new leaf version (i’m not advocating for disabling OP\_CSA), is this how new leaf versions were intended to be used?

> **[GitHub - Christewart/bitcoin at 2024-01-12-new-tapleaf-ver-example](https://github.com/Christewart/bitcoin/tree/2024-01-12-new-tapleaf-ver-example)**
>
> 2024-01-12-new-tapleaf-ver-example

---

<div class="post-metadata">

**Author:** ![halseth](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/halseth/32/198_2.png) [@halseth](https://delvingbitcoin.org/u/halseth)\
**Post date:** [January 18, 2024, 7:56am UTC](https://delvingbitcoin.org/t/deploying-new-taproot-leaf-versions/406/2 "2024-01-18T07:56:00Z")

</div>

Take a look at the commit I linked from my reply in the 64-bit discussion: [64 bit arithmetic soft fork - #18 by halseth](https://delvingbitcoin.org/t/64-bit-arithmetic-soft-fork/397/18)

I basically comes down do defining a new `SigVersion`. This value the interpreter already has access to, hence can choose to behave differently for certain opcodes based on the version.