<p>The control block is the data required to prove that a specific script is within the Taproot tree (script path).</p>
<p>Murch defines the control block <a href="https://murchandamus.medium.com/2-of-3-multisig-inputs-using-pay-to-taproot-d5faf2312ba3" rel="nofollow noreferrer">here</a> (replacing &quot;inner key&quot; with &quot;internal key&quot;):</p>
<blockquote>
<p>When a fallback to the backup key is necessary, the existence of the Taproot tree must be revealed. If there is only a single leaf, the spender provides only the internal key. Tweaking the internal key with the hashed leaf results in the public key. In sum, the data necessary to prove the existence of a script path is called the control block.</p>
</blockquote>
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#script-validation-rules" rel="nofollow noreferrer">BIP 341</a> adds additional details on the &quot;control block&quot;:</p>
<blockquote>
<p>The last stack element is called the control block c, and must have length 33 + 32m, for a value of m that is an integer between 0 and 128, inclusive. Fail if it does not have such a length.</p>
</blockquote>
<p><a href="https://i.sstatic.net/bsZes.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/bsZes.png" alt="BIP 341 Taproot tree" /></a></p>
<p>To prove D (the hash of a particular script) is in the Taproot tree, the control block would need to contain the following data in this order:</p>
<pre><code>&lt;control byte with leaf version and parity bit&gt; &lt;internal key p&gt; &lt;C&gt; &lt;E&gt; &lt;AB&gt;
</code></pre>
<p>To prove D is in the Taproot tree you need to be able to hash up to the Merkle root (ABCDE) and to do that you need to hash <strong>C</strong> with D, then <strong>E</strong> with CD, and then <strong>AB</strong> with CDE.</p>

CC BY-SA 4.0
2021-06-21T16:15:02.103Z
2021-06-21T16:54:13.360Z
2021-06-21T16:54:13.360Z
Michael Folkson
<p>There are two possible ways of spending a Taproot output:</p>
<ul>
<li>Through the <strong>key path</strong>: simply providing a BIP340 signature signing the spending transaction with the public key in the output.</li>
<li>Through the <strong>script path</strong>: revealing that the output was in fact a tweaked key, by revealing the original and the tweak, and showing that this tweak commits to a script leaf. This is where the control block comes into play.</li>
</ul>
<p>When spending through the script path, the signer has to provide a number of pieces of data to let their spend be verified:</p>
<ol>
<li>The revealed script.</li>
<li>The inputs needed to satisfy that script (signatures and whatever other data it may need).</li>
<li>The leaf version (for now, always 0xc0, as specified in BIP342).</li>
<li>The internal key (the public key before tweaking)</li>
<li>The Merkle path to prove that the tweak commits to the revealed script and leaf version (#1 and #2).</li>
<li>A sign bit to indicate whether the output key was negated or not (this is necessary to enable batch validation).</li>
</ol>
<p>The tweak itself is not revealed. It is recomputed by the verifier from the revealed script, leaf version, and internal key. Then it is verified that tweaking the internal key with that tweak matches the public key in the output being spent.</p>
<p>This brings us to the question of how all this information is encoded in the spending input's witness stack:</p>
<ul>
<li>First, all the inputs to the script being spent (#2 above)</li>
<li>As penultimate item, the revealed script (#1 above)</li>
<li>As final item, the <strong>control block</strong>, which contains all the other information:
<ul>
<li>Its first byte stores the leaf version (#3) (top 7 bits) and the sign bit (#6) (bottom bit).</li>
<li>The next 32 bytes store the (X coordinate only, because x-only key) of the internal public key (#4)</li>
<li>Every block of 32 bytes after that encodes a component of the Merkle path (#5) connecting the leaf to the root (and then, the tweak), going in bottom-up direction.</li>
</ul>
</li>
</ul>

CC BY-SA 4.0
2021-06-22T15:39:15.347Z
"Through the script path: revealing that the output was in fact a tweaked key" But every output is a tweaked key right? Even if you pay through the key path it was still a tweaked key. The way you've phrased it here it sounds like for key path spends it isn't a tweaked key (or may not be a tweaked key) https://bitcoin.stackexchange.com/questions/99325/i-want-to-create-a-p2tr-pay-to-taproot-address-but-i-just-need-a-key-path-spen
Michael Folkson
CC BY-SA 4.0
2021-06-22T15:42:05.107Z
The BIP recommends always tweaking, even when there are no script paths. But there is obviously no way to enforce this, because it is not revealed whether or not that is the case for key path spends. It's perfectly possible to take a public key directly, turn it into an address, have someone pay to it, and then spend by signing that directly.
Pieter Wuille
CC BY-SA 4.0
2021-06-22T15:50:29.740Z
Interesting, thanks. So it is a question of whether wallets follow the BIP or ignore this detail in the BIP and take a shortcut here. I was thinking of the BIP as the "standard" that wallets would implement. But yeah I can see the shortcut being taken by some wallets here.
Michael Folkson
CC BY-SA 4.0
2021-06-22T15:56:13.073Z
I don't expect any wallet to take that shortcut, but it doesn't change the fact that if you just see a key path spend, you technically cannot know if it was a tweaked key or not (and if it was, tweaked with what).
Pieter Wuille
CC BY-SA 4.0
2021-06-22T16:02:35.793Z
Just semantics then. If literally zero wallets take the shortcut then you know pretty much every Taproot public key is a tweaked key (whether they need the script path or not). You need some subset of wallets to take the shortcut for there to be uncertainty whether it is a tweaked key or not.
Michael Folkson
CC BY-SA 4.0
2021-06-21T17:20:10.493Z
2021-06-21T17:20:10.493Z
Pieter Wuille
<p>What is the definition of &quot;control block&quot; in the context of Taproot?</p>
<p>It is referred to in <a href="https://github.com/bitcoin/bitcoin/blob/master/src/script/standard.cpp" rel="noreferrer">standard.cpp</a> in the Bitcoin Core repo and in <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#script-validation-rules" rel="noreferrer">BIP 341</a>.</p>

<terminology><taproot>
What is the control block in Taproot?
Michael Folkson
# What is the control block in Taproot?

(Asked by: username_0 on 2021-06-21)

What is the definition of "control block" in the context of Taproot?

It is referred to in [standard.cpp](https://github.com/bitcoin/bitcoin/blob/master/src/script/standard.cpp) in the Bitcoin Core repo and in [BIP 341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#script-validation-rules).

**Tags:** terminology, taproot


---

## 2 answers

### Answer by username_1 on 2021-06-21. Score: 4 | Accepted answer

There are two possible ways of spending a Taproot output:

* Through the **key path**: simply providing a BIP340 signature signing the spending transaction with the public key in the output.
* Through the **script path**: revealing that the output was in fact a tweaked key, by revealing the original and the tweak, and showing that this tweak commits to a script leaf. This is where the control block comes into play.

When spending through the script path, the signer has to provide a number of pieces of data to let their spend be verified:

1. The revealed script.
2. The inputs needed to satisfy that script (signatures and whatever other data it may need).
3. The leaf version (for now, always 0xc0, as specified in BIP342).
4. The internal key (the public key before tweaking)
5. The Merkle path to prove that the tweak commits to the revealed script and leaf version (#1 and #2).
6. A sign bit to indicate whether the output key was negated or not (this is necessary to enable batch validation).

The tweak itself is not revealed. It is recomputed by the verifier from the revealed script, leaf version, and internal key. Then it is verified that tweaking the internal key with that tweak matches the public key in the output being spent.

This brings us to the question of how all this information is encoded in the spending input's witness stack:

* First, all the inputs to the script being spent (#2 above)
* As penultimate item, the revealed script (#1 above)
* As final item, the **control block**, which contains all the other information:
  + Its first byte stores the leaf version (#3) (top 7 bits) and the sign bit (#6) (bottom bit).
  + The next 32 bytes store the (X coordinate only, because x-only key) of the internal public key (#4)
  + Every block of 32 bytes after that encodes a component of the Merkle path (#5) connecting the leaf to the root (and then, the tweak), going in bottom-up direction.

> **Comments:**
> **username_0**: "Through the script path: revealing that the output was in fact a tweaked key" But every output is a tweaked key right? Even if you pay through the key path it was still a tweaked key. The way you've phrased it here it sounds like for key path spends it isn't a tweaked key (or may not be a tweaked key) https://bitcoin.stackexchange.com/questions/99325/i-want-to-create-a-p2tr-pay-to-taproot-address-but-i-just-need-a-key-path-spen  
> **username_1**: The BIP recommends always tweaking, even when there are no script paths. But there is obviously no way to enforce this, because it is not revealed whether or not that is the case for key path spends. It's perfectly possible to take a public key directly, turn it into an address, have someone pay to it, and then spend by signing that directly.  
> **username_0**: Interesting, thanks. So it is a question of whether wallets follow the BIP or ignore this detail in the BIP and take a shortcut here. I was thinking of the BIP as the "standard" that wallets would implement. But yeah I can see the shortcut being taken by some wallets here.  
> **username_1**: I don't expect any wallet to take that shortcut, but it doesn't change the fact that if you just see a key path spend, you technically cannot know if it was a tweaked key or not (and if it was, tweaked with what).  
> **username_0**: Just semantics then. If literally zero wallets take the shortcut then you know pretty much every Taproot public key is a tweaked key (whether they need the script path or not). You need some subset of wallets to take the shortcut for there to be uncertainty whether it is a tweaked key or not.  

---

### Answer by username_0 on 2021-06-21. Score: 1

The control block is the data required to prove that a specific script is within the Taproot tree (script path).

Murch defines the control block [here](https://murchandamus.medium.com/2-of-3-multisig-inputs-using-pay-to-taproot-d5faf2312ba3) (replacing "inner key" with "internal key"):

> When a fallback to the backup key is necessary, the existence of the Taproot tree must be revealed. If there is only a single leaf, the spender provides only the internal key. Tweaking the internal key with the hashed leaf results in the public key. In sum, the data necessary to prove the existence of a script path is called the control block.

[BIP 341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#script-validation-rules) adds additional details on the "control block":

> The last stack element is called the control block c, and must have length 33 + 32m, for a value of m that is an integer between 0 and 128, inclusive. Fail if it does not have such a length.

[![BIP 341 Taproot tree](https://i.sstatic.net/bsZes.png)](https://i.sstatic.net/bsZes.png)

To prove D (the hash of a particular script) is in the Taproot tree, the control block would need to contain the following data in this order:

```
<control byte with leaf version and parity bit> <internal key p> <C> <E> <AB>

```

To prove D is in the Taproot tree you need to be able to hash up to the Merkle root (ABCDE) and to do that you need to hash **C** with D, then **E** with CD, and then **AB** with CDE.


---

