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.
Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It only takes a minute to sign up.
Sign up to join this communityTaproot 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.
* 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 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.
* Length of control block: 1WU
* Header byte (script version, sign of output key): 1WU
* Inner key of root key: 32WU
= 34WU
* Length of control block: 1WU
* Header byte: 1WU
* Inner key of root key: 32WU
* Hashing partner in tree: 32WU
= 66WU
* script size: 1WU
* script "<pk> OP_CHECKSIG": 33+1WU
* Depth 1 Control block: 66WU
57.5+(1+34+66)/4 = 82.75vB
* +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
* +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
* +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.
OP_CHECKSIG
and OP_CHECKSIGVERIFY
are permitted in tapscript, they just expect schnorr signatures then.