Topic: Pay-to-taproot (P2TR) transaction fee (Read 468 times)

This average looks good, pretty close to my latest P2TR consolidation: 19caeede4f289cd4cedd0bb10960a16b93ac0cef5e761451cbdd37d4f7622b7c (2 months ago)

It consisted of 9 P2TR inputs, 1 P2SH-P2WPKH input and 2 P2WPKH outputs.
The virtual size is 683vB which is pretty close to the given figure, a little bit higher considering the change output and for having a different 10th input.

Nice information, but in practice you can't force the receiver to provide you P2WPKH address. So i would make conclusion that Taproot/P2TR address is best option to reduce transaction fee.

Very useful overview, I've featured your compilation in my article about different address types, when I've added Taproot-Addresses recently:

Full post can be seen here.

I've also included it in my German version (a sub-version of my article called "Advantages of using SegWit Addresses) where I found it beneficial to link your article.  

I guess my confusion was that your values seem to be size of the whole input or output, I was thinking in terms of script size and wasn't thinking about the other parts (amount, script length, sequence, etc) that are fixed sizes regardless of the type.

Thank you for the correction, I will edit it and correct it.

I used the above bitcoin size calculator for it directly, the result is similar to when I used the formula (Input*input vsize + output*output vsize + 10 +/- input)

2 mistakes:
1. Technically when you say SegWit, that covers Taproot too. Your comparison here is between version 0 witness program and version 1.
2. Taproot (v1) output size is bigger than P2WPKH (v0) output size but the same size as P2WSH (v0)

P2TR:   OP_1 <32 bytes>
P2WPKH: OP_0 <20 bytes>
P2WSH:  OP_0 <32 bytes>

I'm honestly not sure how the numbers in your 3 tables are computed so I can't comment on them.

Since Taproot was not activated at block 692,261 (that contains the transaction), all the UTXOs being spent in that transaction were considered anyone can spend outputs that didn't need any valid signature or anything like that. Which is exactly how it was spent too!
If you check the tx you can clearly see that the witness field is empty.

here for example transaction of P2TR, (address with - bc1p)

tx

Because Taproot isn't activated yet (about the hours), maybe this is not a standard transaction. f2pool.com helps to mine it with 0 fees.

[1]. https://b10c.me/blog/007-spending-p2tr-pre-activation/

Taproot is far more vast than this, this is just an overview of how taproot transaction fee will look like, it will only cover the taproot transaction fee and nothing more. To know more about Taproot, you can visit the links under 'more about taproot' below.

In any comparison, I will more be using native segwit (P2WPKH) as it has the lowest fee if comparing native segwit with nested segwit, and legacy which has the highest fee, especially the uncompressed legacy address transactions.

Introduction
As a result of schnorr signature in MuSig, keys are aggregated into a single key (master key), providing a valid signature which makes low transaction fee possible as all M-of-N transactions requires only the resulting valid key (master key) and its signature for transactions, this makes multisig payment to have the same fee as single public key transactions.

This is not only limited to multisig transactions but also taproot makes consolidation more possible with low fee as a result of lower input virtual size. Also as a result of lower input virtual size (vbyte), this makes transactions with many inputs but just having one or two outputs very low if compared to segwit (P2WPKH) transactions.


Input and output virtual size (in vbyte)
One of reasons taproot transaction is having low fee is as a result of the transaction input, the input vbyte of taproot transaction is far lower than the input vsize of segwit (P2WPKH). But, its output vsize is otherwise, its output vsize is larger than segwit (P2WPKH) output vbyte, even larger than that of nested segwit and legacy.


Transaction of 1 input and 1 output with the use of Input*input vsize + output*output vsize + 10 +/- input to get the transaction vsize (vbyte).

          Type         |  Input  vbyte | Output vbyte |  transaction vbyte
-------------------------+----------------- +----------------------+--------------------------
          P2TR         |      57.5       |           43           |           111
 Native segwit   |        68         |           31           |         109.5
 Nested segwit  |        93         |           32           |           134
       Legacy         |      140        |            34          |           192 


P2TR, Pay-to-taproot


Although, taproot has low input vsize, but its output vsize is larger and will result to native segwit having slightly lower fee if a transaction is having many outputs with 1, 2 or very few inputs depending on transaction output vsize.

Larger output vsize (vs segwit)
Taproot transaction has 43 vbyte per count, segwit (PWPKH) vbyte per count is 31, this will result to transaction with 1 input, two inputs or very few inputs with very many output to have higher fee if taproot transaction is compared with segwit (P2WPKH) transaction. Taken below table as an example, taproot transaction output vsize in comparison with segwit (P2WPKH) transaction output vsize while the input remain constant as 1. From the table, the more there are more output in a transaction, the more taproot transaction fee will be getting higher if compared with segwit transaction. With 1 or few input while paying to many addresses, segwit (P2WPKH) will save much more on fee.


Transaction count   |         P2TR (in vbyte)         | Native segwit (in vbyte)
-------------------------------+----------------------------------------+-------------------------------------
1 input, 1 outputs    |                   111                    |         109.5       
1 input, 2 outputs    |                   154                    |         140.5       
1 input, 5 outputs    |                   283                    |         233.5       
1 input, 10 outputs  |                   498                    |         388.5     


Benefits of pay-to-taproot in relation to low fee
Although, in few cases, segwit (P2WPKH) transaction fees are lesser than P2TR transaction fee which has been explained above, but there are cases P2TR transaction fee is lower. The first is in multisig transactions, while the second is during high input vsize with just very low output vsize which also result to reduced fee in input consolidation.

Low fee high-input-size transactions and consolidation
P2TR input vsize is lesser than that of segwit (P2WPKH), this makes transactions with high input but low output to be cheaper. Also, this makes consolidation possible with lower fee. P2TR will be a good option for those that often consolidate and people that receives many inputs, just like having a shopping site or a site while using bitcoin as a payment option.

Transaction count    |         P2TR (in vbyte)         | Native segwit (in vbyte)
---------------------------------+---------------------------------------+-------------------------------------
1   input, 1 outputs    |                   111                    |         109.5       
2   input, 1 outputs    |                168.25                 |         177.25       
5   input, 1 outputs    |                   340                    |         380.5       
10 input, 1 outputs    |                626.25                 |         719.25     


Multisig transactions
In m-of-n P2SH and P2WSH transactions, the more the number of keys required in a transaction, the higher the fee. For example, transaction fee that will be required for 1 input and 1 output will be higher for 2-of-5 transaction than in 2-of-3 transactions because the higher the number of keys (m) involved, the higher the transaction fee. With schnorr signature in taproot, even 15-of-15 transactions with 1 input and 1 output will have the same transaction fee like single key wallets, this is as a result of key aggregation in which all the keys involved will be aggregated and produce one valid key and one signature. Only one key and one signature which is valid and help privacy  as blockchain observers will not be able to distinguish between single public key transactions and pay-to-taproot multisig transactions.


Pubkey1 + Pubkey2 + Pubkey = PubkeyX
Signature1 + Signature2 + Signature3 = SignatureX


This will help in people deciding to make use of multisig wallets because they are more secure, providing a means of recovery in a way if 1 key is lost, the fund can be moved to another newly created wallet.


* Also, making consolidation possible with lower fee on multisig wallets.

Probably few people can be discouraged to use multisig wallet to consolidate, the reason is the very high input vsize. The below table shows how 2-of-3 p2sh and p2wsh input vsize are as 2 times or more higher if compared to pay-to-taproot.

   Counts |  P2SH |  P2WSH |   P2TR
--------------+-----------+--------------+---------------
1   input  |   297   |    104.5   |    57.5
2   input  |   594   |      209     |   115
5   input  |  1485  |    522.5   |    287.5
10 input  |  2970  |    1045    |    575

Yet, the transaction fee still also increasing as the number of key needed for transaction increases, this makes P2TR has lower fee while consolidating using multisig wallet.

Conclusion
As a result of keys aggregation, taproot transactions will have low fee just like wallet with single public key. Also, taproot will make input consolidation more cheaper.

Taproot proposal
Open source bitcoin transaction size calculator

More about taproot
Re: [Education] Bitcoin Privacy and Anonymity
Re: Want to know about the technical changes regarding to Taproot Upgrade
Taproot - The biggest upgrade for Bitcoin since 2017 & documents to read

---

More about bitcoin transactions
Minimizing bitcoin transaction fee
Mempool empty! Use this opportunity to Consolidate your small inputs!
List of Bitcoin Mempool Viewers for Reference