I'm thinking about moving all my addresses from Legacy to SegWit (bech32) because I wanna cut down on transaction fees. Plus, if more people switch to SegWit, it should help with network congestion.
I plan to start consolidating my addresses when fees come down due to a less crowded Mempool.
But I'm curious if I should go even further and switch from native SegWit (bech32) to Taproot (bech32m) to save even more on fees.
Anyone have insights on whether Taproot addresses (bech32m) really offer lower fees compared to native SegWit (bech32) addresses?
Segwit version 0 has lower fee than segwit version 1 (pay-to-taproot).
But if you want to consolidate, pay-to-taproot has lower fee.
If you are sending to many addresses like campaign managers on this forum, or your transaction outputs are always far more than the transaction inputs, it is good to use segwit version 0. If you are sending from 1 input to 1 output or 2 outputs, segwit version 0 is lower in fee also. The only time P2TR is of lower fee is when you are no consolidating your high inputs or when the transaction inputs will be far more.
Here's a detailed answer to your question; Taproot (P2TR; pay-to-taproot) addresses are not necessarily cheaper in total but for some cases, its recommended to use P2TR:
More information can be found here: https://murch.one/posts/single-sig-output-types/ (scroll down to "Cost considerations")
It depends.
Each taproot input increases the (virtual) size of the transaction by around 57 vbyte and each bech32 input increases that by around 68 vbyte.
Each taproot output increases the (virtual) size of the transaction by around 43 vbyte and each bech32 output increases that by around 31 vbyte.
For more information, I recommend you to read the topic created by Charles-Tim.
Pay-to-taproot (P2TR) transaction fee
It depends on what transaction you are doing, a taproot transaction isnt always smaller than a native SegWit transaction. A native segwit input is 10 vbytes larger than the taproot input but the output of a native SegWit is 12vbytes smaller than that of a taproot output. This means that for many inputs in a transaction than an output the taproot saves more fees while for a larger output transaction compare to the inputs, the Native segwit transaction saves more fees. That is during consolidation which means multiple inputs to one outputs has you wanted the taproot transaction saves more.
But in a 1-input and 1-output transaction, the native Segwit transactions are quite smaller and save more fees. For me I choose a native SegWit addresses at the moment for ease as the taproot addresses are still not too common in some wallets yet
The SEGWIT protocol actually saves transaction fees by occupying a smaller unit of block space during transactions. This is done segregating the witness data. Since the implementation of the SEGWIT protocol, I am aware of mainly 2 types of SEGWIT addresses.
SEGWIT compatible which was the earliest form of SEGWIT addresses they usually begin with 3The native SEGWIT which is the most popular and economical Bitcoin address. It usually begins with bc I am aware of sweeping your wallet from probably a legacy address to a SEGWIT address however I haven't actually come across an article talking about an address morph or upgrade.
OP isn't talking about nested segwit addresses that start with 3.
OP's question is about segwit version 0 and segwit version 1.
Segwit version 0 addresses are those that start with bc1q. They are also called bech32 addresses.
Segwit version 1 addresses are those that start with bc1p. They are also called bech32m or taproot addresses.
This tool is good for comparison https://bitcoinops.org/en/tools/calc-size/
Change the number of input and output addresses and the type of address and you can know the amount of savings.
Thanks for the heads up
Initially I was of the opinion that bech32 addresses were all the same. Anyways I have a few questions to help me better understand this entire concept.
Overall which of the bech32 addresses are best in terms of minimizing transaction fees? Because from what Charles-Tim explained he made mention of the fact that bech32 version 0 is more economical when it comes to transactions with Large outputs. However I don't really get how bech32m version 1 has an edge over the bech32 version 0 address when it comes to consolidation.
Actually, the fee for a transaction is calculated on the base of data being transmitted in a transaction, and segwit v0 has a small address while Segwit V1 has a larger address, so less data means less fee and more data means more fee. So when we have large outputs, segwit 0 is beneficial because the overall combined address is smaller in comparison to legacy (segwit V1) which is why the fee will be lower.
And talking about why Segwit v1 is better in consolidation, first we should not whats consolidation, its like combining all the small UTXO into one, like on Binance exchange we have small unspendable tokens and we convert them to bnb and then use them to pay the fee, same in here, we can combine any size of UTXO into one and by leveraging the compactness of the locking system of Taproot, size of the tx decreases in consolidation scenario and thus the fees decreases. CMIIW.
With adding any input or output to your transaction, you actually add some data to your transaction.
As I already said in my first reply in this thread if you add one taproot input to your transaction, you increase the (virtual) size of your transaction by around 57 vbyte while that's 68 vbyte for each segwit version 0 input.
In a consolidation transaction, you have multiple inputs and that's why your transaction would be cheaper in fees, if your addresses are segwit version 1.
Thanks to everyone especially Zaguru12, hosseinimr93 and Faisal2202 for your explanations. With your write ups In addition to the little research I just did, I have been able to get a proper understanding of the addresses in question.
Thanks to everyone once again.
FWIW Bech32 and Bech32m are just address format which support multiple witness version. Bech32 has been replaced with Bech32m due to design oversight. But in the future, we'll see new kind of address which also use Bech32m format. So this thread title probably should be "P2WPKH vs P2TR: which ones are cheaper for tx?".