bech32 addresses vs. bech32m addresses: which ones are cheaper for tx?

[Phu Juck]

I'm currently planning to update all of my addresses from Legacy Addresses to SegWit (bech32) Addresses because I want to save more transaction fees when doing transactions. It will also be beneficial because it'll lead to less congestion if everyone switches to SegWit.
I would like to start consolidating my addresses, when transaction fees are getting lower again due to a less congested Mempool.

But I'm wondering if it makes sense to switch even from native SegWit (bech32) to Taproot Addresses (bech32m) to save even more fees.

Does someone know if Taproot Addresses (bech32m) are saving more fees compared to native SegWit (bech32) Addresses?

[Charles-Tim]

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.

[PrivacyOui]

Here's a detailed answer to your question; Taproot (P2TR; pay-to-taproot) addresses are not necessarily cheaper in total but for some cases, it’s recommended to use P2TR:

All four described output types satisfy single-sig usage, although P2TR can do a lot more under the hood. Generally, the transaction cost is cheaper for newer output types: Legacy > Wrapped Segwit > Native Segwit. While the overall cost of P2TR input and output is slightly higher than that of P2WPKH, P2TR shifts a portion of the cost from the input to the output. When you don’t know at what feerate you’ll need to pay to spend your funds later, you should keep them in P2TR outputs, since they’ll have the smallest input cost. Likewise, you should prefer P2TR when others are paying you: the sender pays the output cost while the recipient pays the input cost. Although, you may still bump into some counter-parties that cannot send to bech32, and many that cannot send to bech32m, yet, the economic incentives are clear. If your preferred wallet or service doesn’t support bech32(m) yet, please do ask them to do so.

If you’re considering your transactions’ data footprint on the blockchain, you should also strictly prefer P2TR as it get you the most bang for the byte (see column “raw B” in table above). The data footprint for the output types is P2SH-P2WPKH > P2PKH > P2WPKH > P2TR.

More information can be found here: https://murch.one/posts/single-sig-output-types/ (scroll down to "Cost considerations")

[hosseinimr93]

Does someone know if Taproot Addresses (bech32m) are saving more fees compared to native SegWit (bech32) Addresses?

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

[Zaguru12]

Does someone know if Taproot Addresses (bech32m) are saving more fees compared to native SegWit (bech32) Addresses?

It depends on what transaction you are doing, a taproot transaction isn’t 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

[Mia Chloe]

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 3
• The 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.

[hosseinimr93]

---------

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.

[Yamane_Keto]

Does someone know if Taproot Addresses (bech32m) are saving more fees compared to native SegWit (bech32) 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.

[Mia Chloe]

---------

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.

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.

[Faisal2202]

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.

[hosseinimr93]

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.

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.

[Mia Chloe]

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.

[ABCbits]

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