Leaf Version as Flags

After reading through 64 bit arithmetic soft fork 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

1 Like

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. Given all this, if we ever really need a flag it’s probably better to implement it using OP_SUCCESSx.

1 Like

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

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.

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.