<p>Yes, pretty much. There are a few more constraints, though. From <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-7" rel="nofollow noreferrer">BIP341</a>:</p>
<blockquote>
<ol start="7">
<li><strong>What constraints are there on the leaf version?</strong> First, the leaf version cannot be odd as c[0] &amp; 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.</li>
</ol>
</blockquote>

CC BY-SA 4.0
2022-08-10T18:49:15.467Z
2022-08-10T18:49:15.467Z
Pieter Wuille
<p>With the current TapLeaf version, 0xc0 (192) [parity bit + version] can either be 0xc0 or <strong>0xc1</strong>.</p>
<p>I assume picking the next TapLeaf version as 0xc1 (193) would not work since [parity bit + version] can still be <strong>0xc1</strong> (and 0xc2) which overlaps with a lower TapLeaf version. So I'm assuming TapLeaf versions should be incremented by two.</p>

<taproot>
Are TapLeaf versions meant to be incremented by two?
Burak
# Are TapLeaf versions meant to be incremented by two?

(Asked by: username_0 on 2022-08-10)

With the current TapLeaf version, 0xc0 (192) [parity bit + version] can either be 0xc0 or **0xc1**.

I assume picking the next TapLeaf version as 0xc1 (193) would not work since [parity bit + version] can still be **0xc1** (and 0xc2) which overlaps with a lower TapLeaf version. So I'm assuming TapLeaf versions should be incremented by two.

**Tags:** taproot


---

## 1 answers

### Answer by username_1 on 2022-08-10. Score: 2 | Accepted answer

Yes, pretty much. There are a few more constraints, though. From [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-7):

> 7. **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.


---

