Hey everyone,
Hope I'm in the right spot to ask this. Here's my question:
I'm considering switching to taproot addresses for BTC on layer 1. How do they stack up against Native Segwit addresses? Are taproot transactions cheaper in terms of fees compared to Segwit? How do they do in a basic setup with one input and two outputs, or do they shine more for something like coinjoins with lots of inputs and outputs? I think I heard they offer better privacy features when working with others.
What I'm trying to achieve:
I want to find the best way to save on fees while using layer 1 for transactions.
My goal (if this makes sense):
I’d like to combine my future layer 1 transactions with others using PayJoin/CoinJoin to boost my privacy (make chain analysis tougher) and keep my costs down.
(Since I don't need to rush with my L1 transactions, it should help me get the best fees and plan better)
I got the sense that taproot can condense a lot of info into a single script format, similar to other taproot transactions. Can you share what the upsides and downsides are when moving from Native Segwit to Taproot?
Thanks!
Questions about the benefits and drawbacks of Taproot compared to Native Segwit
11 replies 222 views
You can use this tool https://bitcoinops.org/en/tools/calc-size/ to discover transaction size of Native SegWit (P2WPKH) and Taproot (P2TR). Personally i consider Taproot as good choice due to smaller input size, which lead to lower fee when you spend those Taproot UTXO. But since you mention PayJoin/CoinJoin, you probably want to use whatever address type used by other participant to make tracking more difficulty.
If the transaction have the same inputs and outputs, native segwit transactions are of low fee. If the inputs are more with just one or fewer outputs, taproot transactions have lower fee. If the outputs are more and with just one or few outputs, native segwit transactions are more.
To understand about it more, read this: Pay-to-taproot (P2TR) transaction fee
Native segwit have less output vbyte while taproot has less input vbyte.
It is worth knowing that taproot is also segwit. What you referred to as segwit is referred to as segwit version 0 while taproot is referred to as segwit version 1.
Use that tool or this tool https://jlopp.github.io/bitcoin-transaction-size-calculator/
Compare to Segwit input, an input with Taproot is 10.5 vbyte smaller in size but in an output with Taproot, it is 12 vbyte larger. So depends on inputs and outputs for a transaction, Taproot can be cheaper than Segwit or more expensive.
Thank you for the tool suggestion. Yeah I can see indeed Taproot is even better.
I understand also your point about PayJoin/CoinJoin requiring similar address types, you're trying to tell that while P2TR is more efficient, since other participants don't use it as much for the time being it may not be the optimal choice.
As I was browsing around, I found this https://en.bitcoin.it/wiki/Bech32_adoption . In the past I noticed how somehow Electrum was able to construct UTXOs that were slightly cheaper than what Sparrow Wallet builds, but I will give Sparrow wallet again a try since they seem to have support for Taproot Multisig.
Thanks a lot.
In practice, it's more complicated though. When you send Bitcoin to someone else, you usually can't force them to provide specific type of address (P2WPKH in this case). If you plan to receive Bitcoin from someone else, there's chance their wallet software doesn't support sending to P2TR address.
Don't really know why the adoption is slower than the version 0 , I mean it should be more though its just a slight difference depending on the transaction...maybe that's the case then.
I would speculate the fact SegWit use Bech32, while Taproot use Bech32m contribute to slower Taproot adaption.
Thank you for the link to the previous posts/discussion. Very good stuff to learn about.
Now I can make a better informed decision.
That is true. But I also speculated that Taproot do not exactly reduce transaction fee in single signature wallet. Segwit version 0 still remain to have the lower fee except during spending higher input like during consolidation. It is even surprising that wallets like Electrum and Bluewallet do not support it yet.
Even most bitcoin wallets are supporting segwit version 0 but many centralized platforms like exchanges are not yet supporting it. Exchanges like Bybit, HTX, Bitget, BitMart, Mexc and many other exchanges are not supporting even segwit version 0 up till now.
I understood it.
It's only in hands of us to control if we send bitcoins in our non custodial wallet to another wallet of ours. If we send it to other people, things become harder and nearly out of control.
In forum, signature campaign managers have to force participants to use Bech32 address to save transaction fees in payment broadcast.
Adoption on Segwit Bech32 is better than Taproot Bech32m so I'd prefer to use Bech32 addresses for myself.
https://en.bitcoin.it/wiki/Bech32_adoption
https://txstats.com/d/000000007/bech32-statistics?orgId=1
https://txstats.com/d/000000055/taproot-statistics?orgId=1
^The difference in size of a segwit and taproot TX is negligible and almost identical in single signature so using taproot just only to pay less fee isn't that great idea meanwhile if you're someone who uses multi sig the taproot is for you which saves more fee than segwit. Since it's not really concentrated on lowering the fee like segwit upgrade people never interested in switching to taproot and that's probably one of the reason why most Bitcoin users just stuck with segwit itself for efficient fee.
Related topics
- Curious about the 'Services' section in the peers of Bitcoin Core 6
- Bitcoin Core displaying coins (UTXOs) in a new tab 13
- Are you in favor of BIP-110? Let's get a Bitcoin poll going. 0
- Erlay seems to have some issues here’s a better proposal for a bitcoin protocol without invites 3
- New Optional Hourglass Implementation is Live 3
- Ways to earn some sats by contributing to bitcoin core development 5