Leaf Version as Flags

benthecarman · #1 · 2024-03-20T03:59:20.100Z

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

Vojtěch Strnad · #2 · 2024-03-20T05:26:58.315Z

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.

Chris Stewart · #3 · 2024-04-12T15:40:48.526Z

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.

github.com

bitcoin/bitcoin/blob/0de63b8b46eff5cda85b4950062703324ba65a80/src/script/interpreter.cpp#L1828


      
          
              // Run the script interpreter.
              if (!EvalScript(stack, exec_script, flags, checker, sigversion, execdata, serror)) return false;
          
              // Scripts inside witness implicitly require cleanstack behaviour
              if (stack.size() != 1) return set_error(serror, SCRIPT_ERR_CLEANSTACK);
              if (!CastToBool(stack.back())) return set_error(serror, SCRIPT_ERR_EVAL_FALSE);
              return true;
          }
          
          uint256 ComputeTapleafHash(uint8_t leaf_version, Span<const unsigned char> script)
          {
              return (HashWriter{HASHER_TAPLEAF} << leaf_version << CompactSizeWriter(script.size()) << script).GetSHA256();
          }
          
          uint256 ComputeTapbranchHash(Span<const unsigned char> a, Span<const unsigned char> b)
          {
              HashWriter ss_branch{HASHER_TAPBRANCH};
              if (std::lexicographical_compare(a.begin(), a.end(), b.begin(), b.end())) {
                  ss_branch << a << b;
              } else {

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.

Vojtěch Strnad · #4 · 2024-04-13T13:47:08.422Z · in reply to #3

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.

ProofOfKeags · #5 · 2024-04-15T19:16:34.946Z · in reply to #3

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.