4

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.

Improve this question

2 Answers 2

Reset to default
4

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 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 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.

Improve this answer
6
  • 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
    May 13, 2019 at 18:18
  • 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.
    – Andrew Chow ♦
    May 13, 2019 at 19:03
  • But how about the sum of both - the total cost?
    – Wapac
    May 13, 2019 at 19:52
  • 1
    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.
    – Andrew Chow ♦
    May 13, 2019 at 20:08
  • 2
    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 ♦
    May 13, 2019 at 23:18
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
Improve this answer
2
  • 1
    Taproot is v1, P2PKH and P2WPKH are v0. I'm OP :-)
    – Wapac
    May 21, 2019 at 16:37
  • 1
    P2PKH is a non-segwit output type, not v0 segwit.
    – jnewbery
    May 28, 2019 at 17:33

Your Answer

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

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