I have some doubts about wich format adress to use onchain and why. Any advices?
Taproot
reply
Taproot is not necessarily the best. Taproot inputs are the cheapest to spend, but Taproot outputs are larger than segwit (IIRC taproot is 33 bytes, segwit output is 43), which means in practice Taproot will only be cheaper (assuming all your outputs are Taproot), if your number of inputs are around 16% more than your number of outputs.
However, Taproot has privacy benefits (eventually, although Taproot use is still low). This is because with key aggregation and lightning switching to Taproot, your address will be indistinguishable from a multisig address, or a lightning channel, or... an ordinals inscription address.
Also, I'm not aware of any Taproot coinjoin pools. Sparrow doesn't seem to let me coinjoin my Taproot funds. Are there any out there that someone could point me to?
reply
I've not seen any coinjoins using taproot just yet. Seems to be quite slow adoption with most wallets I use. Some can receive but still not spend!
Still I think taproot will become the new normal so its good to prepare for that now.
reply
not "that" new normal though :D
reply
own nothing happy one?
reply
reply
So...as I see, no benfits at all to use legacy anymore? As community say we should keep it between Native Segwit and Taproot mostly.
reply
Like others are saying, native segwit. Unfortunately still so many services using the old style though, which is annoying.
reply
it doesn't make any sense that binance still shows the legacy address as main bitcoin address
reply
Native segwit, you will save on transaction fees. In old days not everybody supported them, but nowadays it should not be a problem.
reply
213 sats \ 1 reply \ @ek 17 May 2023
Native segwit is the latest address format and is the most efficient which means it has the lowest fees. Prefix is bc1
reply
Fyi: with "latest" I meant latest from the three mentioned formats. Taproot addresses are actually the latest. They start with bc1p. Native segwit is bc1q. Both start with bc1 because both use bech32 encoding.
reply