Bitcoin Forum

So I was updating my hardware wallet minutes ago and I noticed something in my Bitcoin address, it has an extra settings, for the first time I decided to check it out and I found Taproot and Legacy address which I know already.

I knew one was missing, Native SegWit Address, I slide down the screen only to see an extra called Nested Segwit.

What Is the difference between Nested Segwit and Native Segwit?

Nested Segwit Address starts with "3" (P2SH) format

Native Segwit (bech32) starts with "bc1q". It provides lower fee and better security compared to Nested Segwit. It only supports wallet that has bech32. More efficient than Nested Segwit.

It is really simple to be honest.

1. Nested Segwit.
These addresses start with the character "3", and they are actually P2SH addresses so the transactions are wrapped in this format. This makes them compatible with old systems, those that didn't support Segwit right away. This was a good invention at the time because what is the point of native segwit addresses if you can't almost use them anywhere?

This was very useful in the transition to Segwit, but it no longer is.


2. Native Segwit (bech32)
These addresses are in the bech32 format and begin with "bc1". These do not require any wrapping like the former one, but they are not backward compatible so to use them somewhere the wallet or service must support them. However, they are more efficient and provide bigger fee discount as well. There are some more other benefits but they are too technical for the average user.


To be precise they start with "bc1", the "q" means SegWit version 1.

Ruttoshi and BitHodlers have it mostly right. One extra bit: "nested" SegWit is P2SH-wrapped SegWit (usually P2WPKH/P2WSH inside a P2SH "3..." shell). That buys you compatibility with old senders, but you give up some fee savings.

Rough ballpark for a simple spend: legacy P2PKH input ~148 vbytes, nested ~91 vbytes, native bech32 (bc1q...) ~68 vbytes. Both SegWit types fix malleability. It's not that native is "more secure" or anything like that, it's just leaner.

Since you mentioned Taproot in the menu too: Taproot addresses are bech32m and start with bc1p. Some services still lag on bc1p, so if you need max compatibility use nested for now; if your counterparties are modern, default to native bc1q (cheapest, cleaner QR, better checksum).

Also try to keep your change output the same type as what you receive with, or you'll keep dragging expensive legacy change around longer than you want.

As far as I unedrstood it, Nested Segwit begin with a 3 like in Legacy addresses and provide some compatability with older wallets or services.

Native address starts with bc1 and offer all the benefits and it's more effecient, with cheaper transactions and better performance.

Additional points to note: Native segwit is more lightweight than nested segwit, therefore it allows for faster transaction speed.

It has a better error-detection and addresses appear mostly in lower cases for better readability. The only tradeoff of native segwit is that not all platforms support it currently.

You didn't say anything new, this post was not needed..

No, it does not. The speed of transactions is the same regardless of what address type you are using. Transaction capacity of the chain or throughput is something else, it is not speed.

These days pretty much everything supports it unless it is running a dangerously outdated system.

This is my argument, since it makes transactions more lightweight,  more transactions can enter into a block at a time which addresses scalability issues and reduces congestion, thereby allowing more transactions confirmed at a time and this would increase the speed at which transactions are confirmed.

Lol, I like the term "dangerously outdated", however the reason I didn't use "wallet", but "platform" is since I'm referring to exchanges. For example Bitget and Bybit, especially Bitget has only a legacy address. It's yet to support segwit. I can refer to it as running a "dangerously outdated" platform then  :D

Yes, but I believe you are making a mistake. You are talking about transaction capacity or throughput, and that is improved with native segwit. It does not improve transaction speed. Furthermore there is no such thing anyway. Transactions are pretty much instant. We are talking about confirmation speed and that is always the same. On average, under good conditions it is 10 minutes. Reduced congestion does not improve confirmation speed, this is an independent metric. Reducing the block time from 10 minutes to 5 minutes would improve confirmation speed.

You may be talking about an overall average time to get confirmed metric based on all transactions observed, but that is something else and not really useful in my view.

That just means that they are probably running on bought software and they they don't have a serious engineering team behind the platforms. I would not use those under any circumstances.  :D

In addition, while the nested Segwit Address starts with 3, the native Segwit starts with bc1q of which is the address format we are very familiar with. While the native Segwit may be more efficient and has backward compatibility, the nested Segwit is case sensitive and has higher fees too.