Bitcoin Stack Exchange is a question and answer site for Bitcoin users, developers, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
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.
Yes, pretty much. There are a few more constraints, though. From BIP341:
- 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.
