<p>In Bitcoin Optech Newsletter #46, the costs are compared as follows:</p>

<blockquote>
  <p>Overall, this makes the cost to create and spend a Taproot single-sig output about 5% more expensive than P2WPKH.</p>
</blockquote>

<pre><code>                    Vbytes
                P2PKH   P2WPKH  Taproot
scriptPubKey    25      22      35
scriptSig       107     0       0
witness         0       26.75   16.25
Total           132     48.75   51.25
</code></pre>

CC BY-SA 4.0
2019-05-21T16:37:19.267Z
Taproot is v1, P2PKH and P2WPKH are v0. I'm OP :-)
Wapac
CC BY-SA 4.0
2019-05-28T17:33:11.557Z
P2PKH is a non-segwit output type, not v0 segwit.
jnewbery
CC BY-SA 4.0
2019-05-21T12:56:25.040Z
2019-05-21T12:56:25.040Z
Wapac
<p>In general, Segwit v1 is cheaper than segwit v0 to spend but slightly more expensive to create.</p>

<p>Segwit v1 output scripts as defined by the <a href="https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki" rel="nofollow noreferrer">proposed taproot BIP</a> will always be 35 bytes in length. However Segwit v0 output scripts are either 22 bytes (for the single key case) or 34 bytes (script hash case). This means that the person sending to segwit v1 will end up paying a little bit more than for a segwit v0 output. Of course, the recipient can use P2SH wrapped segwit outputs so that cost would actually be pushed to them.</p>

<p>However segwit v1 is cheaper for the recipient when he wants to spend that output. Because segwit v1 is a Pay-to-Pubkey model, the public key does not need to be specified in the input. This saves 34 bytes of witness data (34 weight units, 8.5 vbytes).</p>

<p>Additionally, segwit v0 uses ECDSA signatures which are encoded using the DER encoding. This results in signatures that are typically 71 or 72 bytes (each size has ~50% probability of occurring for any signature unless the software specifically only creates 71 byte signatures like Bitcoin Core does). But segwit v1 uses Schnorr signatures and the encoding specified for that in the BIPs which will typically be 64 bytes in length (can be 65 if something other than SIGHASH_ALL is used but that is rare). For simplicity, we can say that this is a reduction of 8 bytes which is 8 weight units and 2 vbytes.</p>

<p>So for the typical single key case, segwit v1 saves 42 bytes which is 42 weight units or 10.5 vbytes.</p>

<p>Where it gets intereseting is the case of multisigs, the most common type of script used. For multisigs, the <a href="https://eprint.iacr.org/2018/068" rel="nofollow noreferrer">MuSig</a> multisignature scheme. MuSig allows a n-of-n multisig or a m-of-n non-accountable multisig (i.e. no one will be able to know who signed) appear to observers as a single key signature. This means that there is only one public key specified in the output and one signature verified in the input. So for all n-of-n multisigs and non-accountable m-of-n multisigs, the cost is exactly the same as for the single key case, but the savings vary depending on the number of signers. The savings for the first signer are the same as the single key case. For every additional signer (i.e. when n > 1), using segwit v1 saves ~107 bytes, which is 107 weight units or 26.75 vbytes.</p>

<p>It gets more complicated for m-of-n signatures where you want accountability.  Such threshold signatures can be achieved by using MuSig and a merkle tree that represents every combination of signing keys. However the size using sewit v1 will ultimately be smaller than segwit v0 because ultimately, the leaves of the merkle tree will always be single pubkeys and the hashes in between will be slightly smaller than public keys in a traditional script. Lastly, the most common of the thresholds can be used as root case in taproot which allows for more savings as then branches of the script don't need to be revealed.</p>

CC BY-SA 4.0
2019-05-13T18:18:11.183Z
So basically for single user use case of pay to public key or hash, version 0 is cheaper, for everything else including single branch scripts, version 1 is cheaper, would that be fair summation? And by cheaper I mean weight.
Wapac
CC BY-SA 4.0
2019-05-13T19:03:19.650Z
As the spender of inputs, it is always cheaper to use v1. As the creator of outputs, i.e. one sending Bitcoin to others, it is cheaper to send to be sending to v0. But as the sender, you don't really have much choice in what the outputs are as the recipient determines them.
Ava Chow
CC BY-SA 4.0
2019-05-13T19:52:22.207Z
But how about the sum of both - the total cost?
Wapac
CC BY-SA 4.0
2019-05-13T20:08:44.977Z
The least cost would be for you to always give out segwit v1 addresses so your inputs are always segwit v1 and for your outputs to always be segwit v0. But this situation is basically impossible and contradictory. For all of your inputs to always be segwit v1, your change outputs must also be segwit v1. But that contradicts with the requirement for all outputs to be segwit v0. You also cannot dictate what kind of address the receiver gives you. So, in actuality, the best case scenario is to always use Segwit v1.
Ava Chow
CC BY-SA 4.0
2019-05-13T23:18:19.953Z
Great answer, but one nit: MuSig can be used to encode any monotonic boolean function, so you could also encode 2-of-3 in a single pubkey. However that doesn't have accountability. You only need the taproot construction if you need accountability.
Murch
CC BY-SA 4.0
2019-05-28T17:37:06.627Z
@Murch / AndrewChow - I believe musig actually only refers to the method for aggregating n keys into a single key, so on its own can only be used for an n-of-n multisig.

To construct a k-of-n threshold signature scheme (or any monotonic boolean function), you'd need to combine musig with something like pedersen secret sharing. The alternative, as you've noted, is to construct a keytree.
jnewbery
CC BY-SA 4.0
2019-05-13T17:16:12.723Z
2019-05-14T03:07:08.407Z
2019-05-14T03:07:08.407Z
Ava Chow
<p>How do total blockchain cost for Segwit version 0 compare to version 1 which is being proposed? I'm specifically interested in a single user transactions – both paying to public key (or pk hash) and script (mostly asking about scripts without branching as I understand there are savings in more complex scripts with more branches). By total blockchain cost, I mean the number of bytes, vbytes and weight in both the outputs as well as the inputs that are spending these outputs. In other words, I'm asking if there will be any savings in version 1 scripts compared to the transactions that can be done on version 0.</p>

<transaction-fees><segregated-witness><transaction-weight><block-weight><taproot>
On chain cost of Segwit version 1 versus version 0
Wapac
# On chain cost of Segwit version 1 versus version 0

(Asked by: username_0 on 2019-05-13)

How do total blockchain cost for Segwit version 0 compare to version 1 which is being proposed? I'm specifically interested in a single user transactions – both paying to public key (or pk hash) and script (mostly asking about scripts without branching as I understand there are savings in more complex scripts with more branches). By total blockchain cost, I mean the number of bytes, vbytes and weight in both the outputs as well as the inputs that are spending these outputs. In other words, I'm asking if there will be any savings in version 1 scripts compared to the transactions that can be done on version 0.

**Tags:** transaction-fees, segregated-witness, transaction-weight, block-weight, taproot


---

## 2 answers

### Answer by username_2 on 2019-05-13. Score: 4 | Accepted answer

In general, Segwit v1 is cheaper than segwit v0 to spend but slightly more expensive to create.

Segwit v1 output scripts as defined by the [proposed taproot BIP](https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki) will always be 35 bytes in length. However Segwit v0 output scripts are either 22 bytes (for the single key case) or 34 bytes (script hash case). This means that the person sending to segwit v1 will end up paying a little bit more than for a segwit v0 output. Of course, the recipient can use P2SH wrapped segwit outputs so that cost would actually be pushed to them.

However segwit v1 is cheaper for the recipient when he wants to spend that output. Because segwit v1 is a Pay-to-Pubkey model, the public key does not need to be specified in the input. This saves 34 bytes of witness data (34 weight units, 8.5 vbytes).

Additionally, segwit v0 uses ECDSA signatures which are encoded using the DER encoding. This results in signatures that are typically 71 or 72 bytes (each size has ~50% probability of occurring for any signature unless the software specifically only creates 71 byte signatures like Bitcoin Core does). But segwit v1 uses Schnorr signatures and the encoding specified for that in the BIPs which will typically be 64 bytes in length (can be 65 if something other than SIGHASH\_ALL is used but that is rare). For simplicity, we can say that this is a reduction of 8 bytes which is 8 weight units and 2 vbytes.

So for the typical single key case, segwit v1 saves 42 bytes which is 42 weight units or 10.5 vbytes.

Where it gets intereseting is the case of multisigs, the most common type of script used. For multisigs, the [MuSig](https://eprint.iacr.org/2018/068) multisignature scheme. MuSig allows a n-of-n multisig or a m-of-n non-accountable multisig (i.e. no one will be able to know who signed) appear to observers as a single key signature. This means that there is only one public key specified in the output and one signature verified in the input. So for all n-of-n multisigs and non-accountable m-of-n multisigs, the cost is exactly the same as for the single key case, but the savings vary depending on the number of signers. The savings for the first signer are the same as the single key case. For every additional signer (i.e. when n > 1), using segwit v1 saves ~107 bytes, which is 107 weight units or 26.75 vbytes.

It gets more complicated for m-of-n signatures where you want accountability. Such threshold signatures can be achieved by using MuSig and a merkle tree that represents every combination of signing keys. However the size using sewit v1 will ultimately be smaller than segwit v0 because ultimately, the leaves of the merkle tree will always be single pubkeys and the hashes in between will be slightly smaller than public keys in a traditional script. Lastly, the most common of the thresholds can be used as root case in taproot which allows for more savings as then branches of the script don't need to be revealed.

> **Comments:**
> **username_0**: So basically for single user use case of pay to public key or hash, version 0 is cheaper, for everything else including single branch scripts, version 1 is cheaper, would that be fair summation? And by cheaper I mean weight.  
> **username_2**: As the spender of inputs, it is always cheaper to use v1. As the creator of outputs, i.e. one sending Bitcoin to others, it is cheaper to send to be sending to v0. But as the sender, you don't really have much choice in what the outputs are as the recipient determines them.  
> **username_0**: But how about the sum of both - the total cost?  
> **username_2**: The least cost would be for you to always give out segwit v1 addresses so your inputs are always segwit v1 and for your outputs to always be segwit v0. But this situation is basically impossible and contradictory. For all of your inputs to always be segwit v1, your change outputs must also be segwit v1. But that contradicts with the requirement for all outputs to be segwit v0. You also cannot dictate what kind of address the receiver gives you. So, in actuality, the best case scenario is to always use Segwit v1.  
> **username_3**: Great answer, but one nit: MuSig can be used to encode any monotonic boolean function, so you could also encode 2-of-3 in a single pubkey. However that doesn't have accountability. You only need the taproot construction if you need accountability.  
> **username_1**: @username_3 / AndrewChow - I believe musig actually only refers to the method for aggregating n keys into a single key, so on its own can only be used for an n-of-n multisig.  To construct a k-of-n threshold signature scheme (or any monotonic boolean function), you'd need to combine musig with something like pedersen secret sharing. The alternative, as you've noted, is to construct a keytree.  

---

### Answer by username_0 on 2019-05-21. Score: 1

In Bitcoin Optech Newsletter #46, the costs are compared as follows:

> Overall, this makes the cost to create and spend a Taproot single-sig output about 5% more expensive than P2WPKH.

```
                    Vbytes
                P2PKH   P2WPKH  Taproot
scriptPubKey    25      22      35
scriptSig       107     0       0
witness         0       26.75   16.25
Total           132     48.75   51.25

```

> **Comments:**
> **username_0**: Taproot is v1, P2PKH and P2WPKH are v0. I'm OP :-)  
> **username_1**: P2PKH is a non-segwit output type, not v0 segwit.  

---

