# Leaf Version as Flags **URL:** \ **Category:** Protocol Design\ **Tags:** taproot, softfork\ **Created:** [March 20, 2024, 3:59am UTC](https://delvingbitcoin.org/t/leaf-version-as-flags/698 "2024-03-20T03:59:20Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![benthecarman](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/benthecarman/32/1098_2.png) [@benthecarman](https://delvingbitcoin.org/u/benthecarman)\ **Post date:** [March 20, 2024, 3:59am UTC](https://delvingbitcoin.org/t/leaf-version-as-flags/698/1 "2024-03-20T03:59:20Z")
After reading through [64 bit arithmetic soft fork](https://delvingbitcoin.org/t/64-bit-arithmetic-soft-fork/397) and having some discussion about OP\_CAT it seems like it may be better to treat the leaf version as a set a flags rather than a version number. One potential problem is that the current leaf version is 0xc0 which has a binary representation of 11000000, so we’d have 2 flags that default on. Curious on people’s thoughts on using it as flags vs just an incremental version number ---
**Author:** ![vostrnad](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/vostrnad/32/422_2.png) [@vostrnad](https://delvingbitcoin.org/u/vostrnad)\ **Post date:** [March 20, 2024, 5:26am UTC](https://delvingbitcoin.org/t/leaf-version-as-flags/698/2 "2024-03-20T05:26:58Z")
The leaf version must be even which reduces the number of flags to 7, and it cannot be 0x50 (01010000) because that’s the starting byte for the annex. Further restrictions are desirable if we want to support some forms of static analysis, see [footnote in BIP341](https://github.com/bitcoin/bips/blob/b3701faef2bdb98a0d7ace4eedbeefa2da4c89ed/bip-0341.mediawiki#cite_note-7). Given all this, if we ever really need a flag it’s probably better to implement it using OP\_SUCCESSx. ---
**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:** [April 12, 2024, 3:40pm UTC](https://delvingbitcoin.org/t/leaf-version-as-flags/698/3 "2024-04-12T15:40:48Z")
Hi Ben! I don’t believe this can be changed anymore in v1 taproot. We serialize the entire byte representation of the leaf version into the tap leaf hash. In other words, we commit to the full byte rather than an individual bit in the leaf version. > [Whenever we roll out witness version 2, i believe we could change semantics around this](https://github.com/bitcoin/bitcoin/blob/0de63b8b46eff5cda85b4950062703324ba65a80/src/script/interpreter.cpp#L1929). However, when we do roll out version 2 we could totally redefine semantics for leaf versions any way. With the pace we deploy things currently, 256 leaf versions more than adequate imo. ---
**Author:** ![vostrnad](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/vostrnad/32/422_2.png) [@vostrnad](https://delvingbitcoin.org/u/vostrnad)\ **Post date:** [April 13, 2024, 1:47pm UTC](https://delvingbitcoin.org/t/leaf-version-as-flags/698/4 "2024-04-13T13:47:08Z")
Committing to the leaf version byte (i.e. the full set of flags) is exactly what we want. I don’t see how that would be a problem. ---
**Author:** ![ProofOfKeags](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/proofofkeags/32/2035_2.png) [@ProofOfKeags](https://delvingbitcoin.org/u/ProofOfKeags)\ **Post date:** [April 15, 2024, 7:16pm UTC](https://delvingbitcoin.org/t/leaf-version-as-flags/698/5 "2024-04-15T19:16:34Z")
Committing to it would be fine. I think it just means that we have different interpretations of when we have “the next version”. Rather than an enumerated mutually exclusive type we have conjunctions of features. AFAICT that’s still compatible with committing to the whole thing.