<p>You'll find this in <a href="https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki" rel="nofollow noreferrer">BIP342</a>, under <a href="https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#common-signature-message-extension" rel="nofollow noreferrer">common signature message extension</a>. BIP342 signatures reuse most of the BIP341 signature hash structure, but add a few fields of their own, as well as changing a flag bit:</p>
<ul>
<li><strong>The tapleaf hash</strong>: spending using a BIP342 script requires committing to the actual script's hash (the &quot;tapleaf&quot;) to make sure a signature created for one leaf can't be reused in other leaves. This makes it safe to to reuse the same keys multiple times in separate scripts of the same output.</li>
<li><strong>The key version</strong>: since BIP342 allows the introduction of new public key types (without new witness version, leaf version, or new opcodes), there is one reserved byte for indicating what public key type is used for this signature. This is always 0 for now.</li>
<li><strong>The code separator position</strong>: to enable (one of) the uses of OP_CODESEPARATOR to remain in this new model, its semantics were changed. Instead of truncating the &quot;scriptCode&quot; (a concept that no longer exists in taproot scripts), it just records when (in number of executed and/or skipped opcodes) the last OP_CODESEPARATOR was executed, and that number is included in the sighash. If no such opcode was ever executed, the number is 0xffffffff instead. The purpose of this is allowing someone to construct a script that defeats some form of malleability: a signature for a checksig operation before and after an executed OP_CODESEPARATOR cannot be reused in the other position, even if they use the same public key.</li>
</ul>
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="nofollow noreferrer">BIP341</a> describes the general structure of taproot outputs and spending, and the key path spending rules. It describes what script path spending is, but the actual script semantics that apply in this case are left for future extensions. BIP342 specifically describes the script semantics for taproot leaf scripts with leaf version 0xc0. Other leaf versions could be described by future BIPs.</p>

CC BY-SA 4.0
2022-10-25T12:18:18.993Z
2022-10-25T14:24:13.083Z
2022-10-25T14:24:13.083Z
Pieter Wuille
<p>I am trying to follow <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki" rel="nofollow noreferrer">BIP341</a> to understand the signature hash calculation for taproot script path spends.</p>
<p>From the bitcoin testing framework <a href="https://github.com/bitcoin/bitcoin/blob/b5f33ac1f82aea290b4653af36ac2ad1bf1cce7b/test/functional/test_framework/script.py#L813-L814" rel="nofollow noreferrer">code</a>, I see that if the transaction is spending from a script path (as opposed to a key path spend), the sighash needs these additional bytes appended.</p>
<pre><code>    if (scriptpath):
        ss += TaggedHash(&quot;TapLeaf&quot;, bytes([leaf_ver]) + ser_string(script))
        ss += bytes([0])
        ss += struct.pack(&quot;&lt;i&quot;, codeseparator_pos)
</code></pre>
<p>Where are these bytes described in the BIP?</p>
<p>And in case it's not clear from the BIP, what is the purpose for the last two lines: <code>0x00</code> and <code>struct.pack(&quot;&lt;i&quot;, codeseparator_pos)</code>?</p>

<taproot><p2tr><sighash>
What are the last bytes for in a taproot script-path sighash?
Darius
# What are the last bytes for in a taproot script-path sighash?

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

I am trying to follow [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) to understand the signature hash calculation for taproot script path spends.

From the bitcoin testing framework [code](https://github.com/bitcoin/bitcoin/blob/b5f33ac1f82aea290b4653af36ac2ad1bf1cce7b/test/functional/test_framework/script.py#L813-L814), I see that if the transaction is spending from a script path (as opposed to a key path spend), the sighash needs these additional bytes appended.

```
    if (scriptpath):
        ss += TaggedHash("TapLeaf", bytes([leaf_ver]) + ser_string(script))
        ss += bytes([0])
        ss += struct.pack("<i", codeseparator_pos)

```

Where are these bytes described in the BIP?

And in case it's not clear from the BIP, what is the purpose for the last two lines: `0x00` and `struct.pack("<i", codeseparator_pos)`?

**Tags:** taproot, p2tr, sighash


---

## 1 answers

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

You'll find this in [BIP342](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki), under [common signature message extension](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#common-signature-message-extension). BIP342 signatures reuse most of the BIP341 signature hash structure, but add a few fields of their own, as well as changing a flag bit:

* **The tapleaf hash**: spending using a BIP342 script requires committing to the actual script's hash (the "tapleaf") to make sure a signature created for one leaf can't be reused in other leaves. This makes it safe to to reuse the same keys multiple times in separate scripts of the same output.
* **The key version**: since BIP342 allows the introduction of new public key types (without new witness version, leaf version, or new opcodes), there is one reserved byte for indicating what public key type is used for this signature. This is always 0 for now.
* **The code separator position**: to enable (one of) the uses of OP\_CODESEPARATOR to remain in this new model, its semantics were changed. Instead of truncating the "scriptCode" (a concept that no longer exists in taproot scripts), it just records when (in number of executed and/or skipped opcodes) the last OP\_CODESEPARATOR was executed, and that number is included in the sighash. If no such opcode was ever executed, the number is 0xffffffff instead. The purpose of this is allowing someone to construct a script that defeats some form of malleability: a signature for a checksig operation before and after an executed OP\_CODESEPARATOR cannot be reused in the other position, even if they use the same public key.

[BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) describes the general structure of taproot outputs and spending, and the key path spending rules. It describes what script path spending is, but the actual script semantics that apply in this case are left for future extensions. BIP342 specifically describes the script semantics for taproot leaf scripts with leaf version 0xc0. Other leaf versions could be described by future BIPs.


---

