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.

1 Answer 1


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.

  • CHECKSIG, CHECKSIGVERIFY, and CHECKSIGADD all work in BIP342 tapscript. Only CHECKSIGMULTI and CHECKSIGMULTIVERIFY are gone. Sep 2, 2021 at 14:42
  • 1
    OP_CHECKSIG and OP_CHECKSIGVERIFY are permitted in tapscript, they just expect schnorr signatures then.
    – Murch
    Sep 2, 2021 at 14:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.