<p>Taproot generally has two ways of spending. The default way is to spend the output using the <em>key path</em>: pay-to-taproot then behaves like a p2pk output except that it is using a schnorr signature and the corresponding address being encoded using bech32.</p>

<p>The alternative is to reveal that the inner key was tweaked with the root of a Merkle tree, the Merkle path to one of the leafs, and the arbitrary segwit v1 script contained in the leaf, and then to fulfill the spending conditions of this script.</p>

<p>In the following, a 2-of-3 spending condition is split out into three 2-of-2 conditions:</p>

<pre><code>2-of-{A, B, C} = (A &amp;&amp; B) || (A &amp;&amp; C) || (B &amp;&amp; C)
</code></pre>

<p>The assumption is that two of the keys are hot while the third is a backup key for recovery. The default case of spending with the two hot keys is aggregated into the root path pubkey using MuSig. The other two spending conditions using the backup key are stored in leaves of the tree. Two variants are explored: one where the backup key is capable of participating in MuSig signing, another that falls back to a simpler multisig scheme where signing is non-interactive e.g. because the backup key is airgapped and the multiple roundtrips required for MuSig are inconvenient.</p>

<h1>Key path spending costs</h1>

<pre><code>* outpoint (txid:vout): 32+4vB
* scriptSig size: 1vB
* nSequence: 4vB
* num witness items: 1WU
* witness item size: 1WU
* signature: 64WU

32+4+1+4+(1+1+64)/4 = 57.5vB
</code></pre>

<h1>Control Blocks</h1>

<p>Control blocks are used to reveal the script path and prove the inclusion of the script. For a single leaf, the root is equal to the leaf and the tree has a depth of 0 additional layers. Two leaves require a depth of 1.</p>

<h2>Depth 0 control block:</h2>

<pre><code>  * Length of control block: 1WU
  * Header byte (script version, sign of output key): 1WU
  * Inner key of root key: 32WU
= 34WU
</code></pre>

<h2>Depth 1 control block:</h2>

<pre><code>  * Length of control block: 1WU
  * Header byte: 1WU
  * Inner key of root key: 32WU
  * Hashing partner in tree: 32WU
= 66WU
</code></pre>

<h1>Script path spending cost in addition to key path spending cost</h1>

<h2>Script path spend assuming 2-of-2 MuSig leaf</h2>

<pre><code>* script size: 1WU
* script "&lt;pk&gt; OP_CHECKSIG": 33+1WU
* Depth 1 Control block: 66WU

57.5+(1+34+66)/4 = 82.75vB
</code></pre>

<h2>Leafs cannot do MuSig, construction with 2-of-2 OP_CHECKSIG:</h2>

<pre><code>* +2nd sig: 1+64WU
* script size: 1WU
* Script "&lt;pk1&gt; OP_CHECKSIGVERIFY &lt;pk2&gt; OP_CHECKSIG": 33+1+33+1=68WU
* Depth 1 Control block: 66WU

57.5+(1+64+1+68+1+1+32+32)/4 = 107.5vB 
</code></pre>

<h1>Discarded other variants</h1>

<h2>Less efficient construction for 2-of-2 OP_CHECKSIG</h2>

<pre><code>* +2nd sig: 1+64WU
* Length of script: 1WU
* Script "&lt;pk1&gt; OP_CHECKSIG &lt;pk2&gt; OP_CHECKSIGADD 2 OP_EQUAL": 33+1+33+1+1+1=70WU
* Depth 1 Control block: 66WU

57.5+(1+64+1+70+66)/4 = 108vB
</code></pre>

<h2>Less private, more costly variant with a single 2-of-3 leaf in lieu of two 2-of-2 leaves:</h2>

<pre><code>* +2nd sig: 1+64WU
* +1 empty witness item: 2WU
* Length of script: 1WU
* Script "&lt;pk1&gt; OP_CHECKSIG &lt;pk2&gt; OP_CHECKSIGADD &lt;pk3&gt; OP_CHECKSIGADD 2 OP_EQUAL": 33+1+33+1+33+1+2=104WU
* Depth 0 Control block:

57.5+(1+64+2+1+104+1+1+32)/4 = 109vB
</code></pre>

<hr>

<p><sup>Disclaimer: All data best effort, don't trust, verify. Also, please correct me, if I made a mistake somewhere.</sup></p>

CC BY-SA 4.0
2021-09-02T14:42:30.580Z
CHECKSIG, CHECKSIGVERIFY, and CHECKSIGADD all work in BIP342 tapscript. Only CHECKSIGMULTI and CHECKSIGMULTIVERIFY are gone.
Pieter Wuille
CC BY-SA 4.0
2021-09-02T14:43:13.070Z
`OP_CHECKSIG` and `OP_CHECKSIGVERIFY` are permitted in tapscript, they just expect schnorr signatures then.
Murch
CC BY-SA 4.0
2020-05-19T04:20:53.930Z
2020-05-27T21:38:18.013Z
2020-05-27T21:38:18.013Z
Murch
<p>There was a Twitter discussion about the sizes of inputs and Taproot came up. What are the input sizes for Taproot inputs?</p>

<p>Please cover both the key path spend (single-sig or default spend) and 2-of-3 multisig script path spends.</p>

<multi-signature><transaction-input><transaction-weight><taproot>
What are the sizes of single-sig and 2-of-3 multisig taproot inputs?
Murch
# What are the sizes of single-sig and 2-of-3 multisig taproot inputs?

(Asked by: username_0 on 2020-05-19)

There was a Twitter discussion about the sizes of inputs and Taproot came up. What are the input sizes for Taproot inputs?

Please cover both the key path spend (single-sig or default spend) and 2-of-3 multisig script path spends.

**Tags:** multi-signature, transaction-input, transaction-weight, taproot


---

## 1 answers

### Answer by username_0 on 2020-05-19. Score: 7 | Accepted answer

Taproot generally has two ways of spending. The default way is to spend the output using the *key path*: pay-to-taproot then behaves like a p2pk output except that it is using a schnorr signature and the corresponding address being encoded using bech32.

The alternative is to reveal that the inner key was tweaked with the root of a Merkle tree, the Merkle path to one of the leafs, and the arbitrary segwit v1 script contained in the leaf, and then to fulfill the spending conditions of this script.

In the following, a 2-of-3 spending condition is split out into three 2-of-2 conditions:

```
2-of-{A, B, C} = (A && B) || (A && C) || (B && C)

```

The assumption is that two of the keys are hot while the third is a backup key for recovery. The default case of spending with the two hot keys is aggregated into the root path pubkey using MuSig. The other two spending conditions using the backup key are stored in leaves of the tree. Two variants are explored: one where the backup key is capable of participating in MuSig signing, another that falls back to a simpler multisig scheme where signing is non-interactive e.g. because the backup key is airgapped and the multiple roundtrips required for MuSig are inconvenient.

# Key path spending costs

```
* outpoint (txid:vout): 32+4vB
* scriptSig size: 1vB
* nSequence: 4vB
* num witness items: 1WU
* witness item size: 1WU
* signature: 64WU

32+4+1+4+(1+1+64)/4 = 57.5vB

```

# Control Blocks

Control blocks are used to reveal the script path and prove the inclusion of the script. For a single leaf, the root is equal to the leaf and the tree has a depth of 0 additional layers. Two leaves require a depth of 1.

## Depth 0 control block:

```
  * Length of control block: 1WU
  * Header byte (script version, sign of output key): 1WU
  * Inner key of root key: 32WU
= 34WU

```

## Depth 1 control block:

```
  * Length of control block: 1WU
  * Header byte: 1WU
  * Inner key of root key: 32WU
  * Hashing partner in tree: 32WU
= 66WU

```

# Script path spending cost in addition to key path spending cost

## Script path spend assuming 2-of-2 MuSig leaf

```
* script size: 1WU
* script "<pk> OP_CHECKSIG": 33+1WU
* Depth 1 Control block: 66WU

57.5+(1+34+66)/4 = 82.75vB

```

## Leafs cannot do MuSig, construction with 2-of-2 OP\_CHECKSIG:

```
* +2nd sig: 1+64WU
* script size: 1WU
* Script "<pk1> OP_CHECKSIGVERIFY <pk2> OP_CHECKSIG": 33+1+33+1=68WU
* Depth 1 Control block: 66WU

57.5+(1+64+1+68+1+1+32+32)/4 = 107.5vB 

```

# Discarded other variants

## Less efficient construction for 2-of-2 OP\_CHECKSIG

```
* +2nd sig: 1+64WU
* Length of script: 1WU
* Script "<pk1> OP_CHECKSIG <pk2> OP_CHECKSIGADD 2 OP_EQUAL": 33+1+33+1+1+1=70WU
* Depth 1 Control block: 66WU

57.5+(1+64+1+70+66)/4 = 108vB

```

## Less private, more costly variant with a single 2-of-3 leaf in lieu of two 2-of-2 leaves:

```
* +2nd sig: 1+64WU
* +1 empty witness item: 2WU
* Length of script: 1WU
* Script "<pk1> OP_CHECKSIG <pk2> OP_CHECKSIGADD <pk3> OP_CHECKSIGADD 2 OP_EQUAL": 33+1+33+1+33+1+2=104WU
* Depth 0 Control block:

57.5+(1+64+2+1+104+1+1+32)/4 = 109vB

```

---

Disclaimer: All data best effort, don't trust, verify. Also, please correct me, if I made a mistake somewhere.

> **Comments:**
> **username_1**: CHECKSIG, CHECKSIGVERIFY, and CHECKSIGADD all work in BIP342 tapscript. Only CHECKSIGMULTI and CHECKSIGMULTIVERIFY are gone.  
> **username_0**: `OP_CHECKSIG` and `OP_CHECKSIGVERIFY` are permitted in tapscript, they just expect schnorr signatures then.  

---

