What is the difference between Segwit? Native Segwit? Legacy? Which one better?

[niccolo_21]

I've been reading the topic but couldn't find an answer to my issue, which is real simple:

what the heck do I choose??   



I have a BitStamp account waiting and still cant understand if I need to activate a Native Segwit or Segwit account on my Ledger Live ..

I have found this article on the news announcement section of BitStamp but wasnt able to find out where my address belongs and still cant move on

[1713879480]

1713879480

[1713879480]

1713879480

[1713879480]

1713879480

[Rath_]

what the heck do I choose??    

Since BitStamp supports SegWit, I would recommend you choosing a native SegWit address in the Ledger Live. Nested SegWit ensures 100% compatibility with services which don't support SegWit yet, but you will save a bit less on fees in the future if you choose it.

[niccolo_21]

Since BitStamp supports SegWit, I would recommend you choosing a native SegWit address in the Ledger Live. Nested SegWit ensures 100% compatibility with services which don't support SegWit yet, but you will save a bit less on fees in the future if you choose it.

so, Nested Segwit is synonymous to Segwit, not Native Segwit..

and Native Segwit is synonymous to Bech32, right?


but on this wiki it reports BitStamp as not yet adopting bech32 .. 

and a stupid question, why is it that if it was introduced later they called it "Native", just to add some more confusion .. 

[AdolfinWolf]

but on this wiki it reports BitStamp as not yet adopting bech32 ..  

Might be outdated. I haven't used Bitstamp, but i'd be surprised if they didn't let you withdraw to bech32 adresses by now.

Edit: actually, as per May, they didnt seem to support it either: https://github.com/spesmilo/electrum-docs/issues/92
Not sure if that's already changed.

and a stupid question, why is it that if it was introduced later they called it "Native", just to add some more confusion ..  

Because the bech32 implementation makes use of all the advantages Segwit has to offer, whereas nested segwit (3.. adresses) doesn't.
I'm assuming that's why they called the former "Native" because it's a more "complete" implementation.

Basically: https://bitcoin.stackexchange.com/a/74792, and if you're interested as to why bech32 adresses are cheaper; https://bitcoin.stackexchange.com/a/78934

ed: This site seems to give a good alternative overview of services that support segwit next to the wiki. https://segwit.support/ (Wtf Binance!)

[Rath_]

so, Nested Segwit is synonymous to Segwit, not Native Segwit..
and Native Segwit is synonymous to Bech32, right?

SegWit is a protocol upgrade. Nested SegWit is a type of address which starts from 3 and offers full compatibility while providing some benefits of the native SegWit. Native SegWit is also referred to as the bech32 address (it starts from bc1).

but on this wiki it reports BitStamp as not yet adopting bech32 ..  

Oh, you're right. It's weird that they don't allow sending to bech32 addresses while generating nested SegWit ones. Choose a nested SegWit address then. It should start with 3 and it will be completely compatible with all services. I am sorry for confusing you.

[niccolo_21]

SegWit is a protocol upgrade. Nested SegWit is a type of address which starts from 3 and offers full compatibility while providing some benefits of the native SegWit. Native SegWit is also referred to as the bech32 address (it starts from bc1).

Oh, you're right. It's weird that they don't allow sending to bech32 addresses while generating nested SegWit ones. Choose a nested SegWit address then. It should start with 3 and it will be completely compatible with all services. I am sorry for confusing you.

but on this wiki it reports BitStamp as not yet adopting bech32 ..  

Might be outdated. I haven't used Bitstamp, but i'd be surprised if they didn't let you withdraw to bech32 adresses by now.

Edit: actually, as per May, they didnt seem to support it either: https://github.com/spesmilo/electrum-docs/issues/92
Not sure if that's already changed.

and a stupid question, why is it that if it was introduced later they called it "Native", just to add some more confusion ..  

Because the bech32 implementation makes use of all the advantages Segwit has to offer, whereas nested segwit (3.. adresses) doesn't.
I'm assuming that's why they called the former "Native" because it's a more "complete" implementation.

Basically: https://bitcoin.stackexchange.com/a/74792, and if you're interested as to why bech32 adresses are cheaper; https://bitcoin.stackexchange.com/a/78934

ed: This site seems to give a good alternative overview of services that support segwit next to the wiki. https://segwit.support/ (Wtf Binance!)

thanks to you both for your answers and link suggestions.

In the end I opened a ticket with BitStamp Support and asked them about it, after all that piece of news dates back to 2017: probably it just referred to Segwit, not native segwit.

And in fact my personal BTC address on BitStamp begins with 3, as you mentioned.

let's hear what they say

[niccolo_21]

so, I got the answer from BitStamp Support. They confirmed that at the moment they don't support withdrawals to Bech32 address formats, and suggested me for a P2SH format address: does this sound somewhat new to you or is it one of those kinds we already mentioned?

[bob123]

so, I got the answer from BitStamp Support. They confirmed that at the moment they don't support withdrawals to Bech32 address formats, and suggested me for a P2SH format address: does this sound somewhat new to you or is it one of those kinds we already mentioned?

P2SH is nested segwit (addresses starting with 3..).
It is quite sad that a lot of sites didn't upgrade their software yet to support bech32, but i guess why bother investing 5 minutes if you simply can stay outdated and risk losing customer in the future 


Also, nested segwit is not a synonym to segwit (at least it should not).

Bech32 = native segwit = (real) segwit
P2SH = nested segwit = P2WPKH nested into P2SH
P2PKH = legacy

[niccolo_21]

ok thanks, thanks for your explanation.

I perfectly understand your technical approach, but when I ask

so, Nested Segwit is synonymous to Segwit, not Native Segwit..
and Native Segwit is synonymous to Bech32, right?

what I am trying to do is try do understand in the first place is the meaning of this picture, i.e. the meaning of the difference between segwit and native segwit in this particular case.


as you can see, the picture doesn't mention bech 32, nested or whatever. It just mentions segwit vs native segwit, and I have to figure out which is which. That's why I asked

so, Nested Segwit is synonymous to Segwit, not Native Segwit..
and Native Segwit is synonymous to Bech32, right?

I need to understand: if I choose Native Segwit I am choosing a Bech32 format address (which now we discovered is not supported in BitStamp), but if I choose the other option, which is referred to as just Segwit, what the hell am I choosing??

That's what I would love to understand before setting up the address

[Carlton Banks]

I need to understand: if I choose Native Segwit I am choosing a Bech32 format address

yes

(but Bitstamp can't send to those, as you know)

but if I choose the other option, which is referred to as just Segwit, what the hell am I choosing??

if they're calling it "Segwit", and choosing that gives your Ledger an address starting with a 3, then it's nested segwit. Maximum compatibility, hence why Bitstamp can send to that type

[niccolo_21]

ok, this may be the answer I was looking for:

Bitcoin address formats

Native SegWit addresses start with bc1. These are bech32 addresses that offer better protection against typos and are cheaper to spend from on top of the advantages of SegWit addresses.

SegWit addresses start with a 3. The SegWit upgrade reduces network fees, speeds up transaction signing on hardware wallets, and enables second-layer solutions like Lightning Network.

Legacy addresses start with a 1. This is an older Bitcoin address format. Legacy addresses previously generated using a Ledger hardware wallet will show up when adding an account, but new legacy accounts cannot be added.

source, Ledger's own support page
https://support.ledger.com/hc/en-us/articles/115005195945

[niccolo_21]

so it should be a Nested Segway, like you guys mentioned.

Now, the point is: if I wanted my amount of btc stored in the latest format (bech32 - Native Segwit) and given that BitStamp does not provide this kind of transfer, what can I do?

All I can figure out is just

• withdraw to a "regular" Segwit address (starting with 3) for the moment
• wait for Bitstamp to upgrade
• move the amount back to bitstamp, on a upgraded Native Segwit Address
• move it back once again to your ledger nano s, this time on a Native Segwit Address

any wiser suggestion?

[bob123]

any wiser suggestion?

• Withdraw to P2SH address
• Send to bech32 address

But it isn't really necessary to pay an additional fee just to have them on a bech32 type address.
You might just use P2SH for all service and sites which do not accept bech32 yet (e.g. bitstamp), and use bech32 for all other transactions.

[Rath_]

Now, the point is: if I wanted my amount of btc stored in the latest format (bech32 - Native Segwit) and given that BitStamp does not provide this kind of transfer, what can I do?
-snip

There is a much easier way. You can send all of your funds from BitStamp to your nested SegWit address. Generate a native SegWit address in the Ledger Live and transfer your coins there from your nested SegWit address. You don't have to move them to BitStamp again. While transfering coins between your addresses, you can set a low fee (1 sat/byte).

[Carlton Banks]

so it should be a Nested Segway, like you guys mentioned.

correct the word in bold please

and try not to use your phone to access the forum, it will make these autocorrect mistakes and confuse people reading the thread

Now, the point is: if I wanted my amount of btc stored in the latest format (bech32 - Native Segwit) and given that BitStamp does not provide this kind of transfer, what can I do?

All I can figure out is just

• withdraw to a "regular" Segwit address (starting with 3) for the moment
• wait for Bitstamp to upgrade
• move the amount back to bitstamp, on a upgraded Native Segwit Address
• move it back once again to your ledger nano s, this time on a Native Segwit Address

you're overcomplicating it


just use nested Segwit until you've figured it out, it's the simplest way of reducing any potential mistakes

[niccolo_21]

Guys,
please allow me to tell you that you are not good at explaining and informing. It's not enough in my opinion to research and study, because if you can't explain a concept (simple, like this one is) concisely and with simple words to someone who is trying to understand, that's not exemplary in my opinion.

It took days and days of posting and in the end I had to be the one to come up with the simplest and most efficient of tools: a simple table. A plain. Simple. Table.

All you could provide were fragmentary, incomplete, disjointed and often conflicting pieces of answers. Ok.

That being said,

now please let me try to sort this out once for all with my humble tools and knowledge.


Now, if the info shown in the following chart is correct (and please don't bother remarking minor misunderstandings in the attempt to reaffirm your expertise: it should be clear by now what we are talking about and what I am focusing on)

Address Format	Beginning with	Age & Diffusion	Synonim to	BitStamp Supported	Ledger Supported
Bech32	bc1	Most recent one, still not massively widespread	Native Segwit	no	yes
P2SH	3	The "classic" one, the matter-of-fact standard as to adoption	Nested Segwit	yes	yes
P2PKH	1	The "old" one, doesn't make much sense anymore to activate this kind of address now	Legacy?	we don't care	we don't care

how is that even possible to perform the kind of action suggested by these users?

• Withdraw to P2SH address
• Send to bech32 address

There is a much easier way. You can send all of your funds from BitStamp to your nested SegWit address. Generate a native SegWit address in the Ledger Live and transfer your coins there from your nested SegWit address. You don't have to move them to BitStamp again. While transfering coins between your addresses, you can set a low fee (1 sat/byte).

If the BitStamp address (which is in the P2SH format as we confirmed) is not able to send funds to a bech32 address in the first place, how can I send them from BitStamp to a P2SH address and THEN send them to a bech32 once again? If these two kinds of address don't interact with eachother from BitStamp towards Ledger, why would they interact from Ledger to Ledger? I would have done this in the first place straigh from BitStamp, wouldn't I?

Does this imply that the compatibility between the two address formats is not "address-related" but rather "platform-related"? Let me repeat that: Why if these two kind of addresses don't interact with eachother from BitStamp towards Ledger, why would they interact from Ledger to Ledger??


Is it so bizarre assuming that such an important focus should be explained and taken care of when answering to someone who is asking for information, who is trying to understand how the hell all this works?

Don't you agree with me, men?

[bob123]

~snip~

how is that even possible to perform the kind of action suggested by these users?

• Withdraw to P2SH address
• Send to bech32 address

[...]

If the BitStamp address (which is in the P2SH format as we confirmed) is not able to send funds to a bech32 address in the first place, how can I send them from BitStamp to a P2SH address and THEN send them to a bech32 once again? If these two kinds of address don't interact with eachother from BitStamp towards Ledger, why would they interact from Ledger to Ledger? I would have done this in the first place straigh from BitStamp, wouldn't I?

You can send from any address type to any address type.

When you try to withdraw coins from bitstamp (or any other site), the website itself does a check to see if the address is valid.
For example, if you paste "helloo" into the address field, you get an error message that this is not a valid bitcoin address.

Bitstamp simply didn't update their software for a long time, so that once they see the string you entered starts with "bc1..", the software says "whoa whoa.. it is not starting with 1 or 3, so can't be a valid address", and therefore refusing to proceed with the withdrawal.

They simply didn't update their code.


Each wallet accepts transactions from each address type to each address type.
This is not an issue at all.


Protocol-wise, it definitely is possible.
Each desktop-/mobile-/hardware- walllet supports that.

Just quite a few shitty outdated online-services don't, because they didn't update their webserver code where the sanity check is happening.

Address Format	Beginning with	Age & Diffusion	Synonim to	BitStamp Supported	Ledger Supported
P2SH	3	The "classic" one, the matter-of-fact standard as to adoption	Nested Segwit	yes	yes

P2SH is not segwit.
P2SH can also be a multi-signature address.

You won't know what kind of address this is after coins have been spent from it and you can take a look at the redeem script.


Nested segwit is P2WPKH nested into P2SH.
P2SH itself does not mean the address is a segwit-type address. Change the address format in this line to P2SH-P2WPKH and your table is correct.
The column "ledger supported" is quite senseless too.

[niccolo_21]

Does this imply that the compatibility between the two address formats is not "address-related" but rather "platform-related"? Let me repeat that: Why if these two kind of addresses don't interact with eachother from BitStamp towards Ledger, why would they interact from Ledger to Ledger??

so you are confirming that this type of interaction is sort of platform-related, meaning that it won't be the address to stop you from moving your funds but rather the platform which hosts that address if that platform is not up-to-date yet. Right?

This should explain your suggestion in the end: i.e. a P2SH  <-->  bech32 transfer from BitStamp to Ledger will not work; but a P2SH  <-->  bech32 transfer from Ledger to Ledger will work because Ledger's software is "ready" to that. Right?

[bob123]

so you are confirming that this type of interaction is sort of platform-related, meaning that it won't be the address to stop you from moving your funds but rather the platform which hosts that address if that platform is not up-to-date yet. Right?

I don't like the term 'platform-related', but in the end that's how it is.
I am convinced that the wallet which the platform (in this case: bitstamp) is using, accepts bech32.

It is just the website/webserver which checks if the entered address is a valid one which returns 'false' upon a bech32 address being entered.


So.. in the end.. yes. This is just because the platform/website didn't update their webserver code yet.

This should explain your suggestion in the end: i.e. a P2SH  <-->  bech32 transfer from BitStamp to Ledger will not work; but a P2SH  <-->  bech32 transfer from Ledger to Ledger will work because Ledger's software is "ready" to that. Right?

Yes.
Each half-way up-do-date software will allow you to send coins to a bech32 address. This includes hardware-/mobile-/desktop- and some webwallets.

[niccolo_21]

ok, thanks