Topic: What is the difference between Segwit? Native Segwit? Legacy? Which one better? (Read 977 times)

This graphics is quite inaccurate.


P2PKH type addresses always start with 1.. and P2SH always start with 3...




P2SH has been here since ( almost) the beginning.
P2SH (and therefore multisig addresses) got introduced 2012.

Each wallet supports these. At least it should if it is considered a somewhat proper wallet.

P2SH is nothing new.
P2WPKH nested into P2SH (nested segwit) is somewhat new, but the addresses are not distinguishable until one has used its private key to create a transaction.


Additionally i am missing a few pros/cons for each type on that graphic.

Source:

https://in.pinterest.com/pin/605241637403633867/

everything you needed to understand the two segwit types is on page 1 of this thread. we're only on page 3 right now.

Hey Carlton,

it's quite singular that you mistake trying to understand for "complicating" ..

if I wanted some suggestions on what to do without knowing what I am doing I would probably follow your advice. But I am trying to comprehend how this works: if you can help on that, fine; if you wish I would follow blind instructions that's not the case.

I see you haven't changed since the times of Bel Air, always blindingly trying to feed your ego  .. Massively.. 

https://www.youtube.com/watch?v=4cpVFkF2dno

you're overcomplicating it still. massively.

just use the nested segwit addresses. the ones starting with a 3

it's easy. you can't go wrong that way

ok, thanks

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.




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.

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?

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.

---

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.

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?





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?

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



you're overcomplicating it


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

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).

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

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?

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




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

yes

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



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

ok thanks, thanks for your explanation.

I perfectly understand your technical approach, but when I ask


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

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

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

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?

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

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.

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.

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!)

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

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.

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

It is a pure validation issue, no need for the 'likely' part. Implementing native Segwit decoding is really easy if you look at the examples from the BIP. If their software team is that unqualified they could just bulk source addresses from Bitcoin Core. 

Correct.

No... I'm talking about sending to and it really has nothing to do with full nodes... it is simply bad programming on the part of the sites.

Example: Site/Wallet asks you to put your withdrawal address in or the address you want to send to... you enter a bc1 address it says "invalid address"... that is most likely a pure validation issue. Users are then like "Why cannot I send from to my "bc1" address?"... and this ends up causing confusion and the incorrect belief that you can only send to certain types of addresses from specific address types.

It's probably more correct to say that you can only send to certain address types from some specific wallets/sites... but that's not an issue with Bitcoin, that's because those specific wallets/sites are "broken".

Ah I'm on about sending to, you're on about sending from.

A lot of sites still don't support native segwit. They've built brand new websites in that time some of them too and still don't accept it... But yes bad form validation also needs to be blamed.

I doubt that is true... it more likely a result of "broken" programming that is doing address validation based purely on Base58 P2PKH and P2SH address formats... that is to say... "1" or "3"-type addresses.

The fallacy that "you can't send from X-type address to Y-type address" came about because certain (popular) websites just don't (or didn't) recognise bech32 addresses (aka "bc1") as being "valid" address types. It has nothing to do with whether or not they're running full nodes.

For instance, you can have v0.17.1 of Bitcoin Core running in the backend, but if your frontend UI is not setup to accept "bech32" as a valid address... then it's still not going to let you send to a bc1 address

The only time transactions don't work is when exchanges or wallets done host from full nodes.

All implementation is deigned to be backwards compatible (when possible) and this is no exception. Any core node after about v0.9 (I think) will recognise segwit as being fairly standard as a transaction and will process it through. The errors come when wallets and services done rely on full nodes for transaction data and instead use sloppy programming to contact random nodes it trusts...

P2SWH afaik is essentially the same as all the other transactions its just that the signed part is removed and placed elsewhere in order to increase the limit of the blocks.

---

Wow I was stupid 15 months ago...

Yep, that's right



Not totally right, but it's not relevant why that's wrong for this discussion

---

Basically:

Either your software supports native SW, or it doesn't (because native SW is newest).

Until your software supports native SW, use the script-wrapped addresses instead (addresses beginning with a 3)

all of them work and there is no end goal here. think of SegWit as the additional features that we added on top of bitcoin. now to use those features you have to upgrade. otherwise you can send from any address to any other address without a problem.
the fact that you couldn't send bitcoin from Binance account to a bc1 address only shows that Binance has not yet upgraded their system even though more than a year has passed.

the answer to all of the above is YES.


we have P2WPKH which is the bc1 or bech32 addresses, these require clients to be upgraded
we have P2PKH which is the 1 or base58 or legacy addresses, this should work without upgrade since it is the old version
we have P2SH which is the multi sig and has nothing to do with SegWit and should work like the last one
we have P2WSH which is the nested SegWit where we use a workaround to get an address which starts with 3 and looks the same as P2SH so that old clients without upgrade can work with this one too if they are lazy enough not to upgrade.

I've read all of these replies, as well as other threads over the last couple of years, and I must say I still am confused about one thing.

What wallets can send to what wallets. It is not an any combination is ok thing because each time I've tried to make a SegWit wallet to support the ecosystem, I run into trouble. It seems to me there are 9 types of transactions. Which work and which don't? The end goal is to get everyone on Bc1 right? Most of the replies to "can I send from this to that" seem to be yes, but I have not had that fortune. Every time I've tried I've been denied. I can't remember what I tried as I've tried a few times over the last year or 2 or however long it's been. One that I remember in particular is trying to send Bitcoin from Binance to I believe a Bc1? It was Electrum, and I don't remember if it was Bc1 or P2SH nested.

Please explain if I am mis understanding, and can someone copy paste this and fill in the ?'s and confirm or deny the Yes?'s

Legacy > Legacy = Yes
Legacy > P2SH = Yes?
Legacy > Bech1/Bc1 = ?

P2SH > Legacy = ?
P2SH > P2SH = Yes
P2SH > Bc1 = Yes

Bc1 > Legacy = ?
Bc1 > P2SH = Yes?
Bc1 > Bc1 = Yes

Also am I using P2SH nomenclature correctly? Or should I be referring to the hybrid/bridge addresses as P2WPKH? or should I be technical and say "P2WPKH nested into P2SH"? What is the proper shorthand?

I sent to the segwit address now, and it worked.

Sending 100k satoshis from the legacy address results in a 98k satoshi fee. Sending this same value from the segwit address results in a 83k satoshi fee. That is a 15% difference.

No, that's not how it works. The segwit adress doesn't do anything for a legacy adress.. You will indeed need to send the funds to a segwit compatible adress to make a segwit transaction from there, as explained above.

You just simply made a legacy transaction, hence why the fees remained the same.

So yes, you should've sent them from the exchange to a segwit adress.

I believe to then send them back will also give you the reduced fees, even if the exchange doesn't support segwit adresses. ( eg. if they still use the 1... standard adresses.) ( Would love if someone could correct me if i'm wrong on this.).

I did some experiment. Sent a bit more than 0.006btc from a exchange to a new wallet. Before sending, I assigned the only address on this wallet a segwit address. After adding the segwit address, I sent from the exchange to the initial legacy address, not the segwit one.

Then closed QT, got back to the August wallet, re-open QT, and tried to sent 0.005btc from there to the exchange. The fee was 98000 satoshis, approximately. Since I was only checking, I didnt sent the value.

Closed QT again, switched to the new wallet, re-open QT, and tried to sent 0.005btc from this one to the exchange, got the same 98000 satoshis fee. Again, I was only checking, but I got the same fee to send 500000 satoshis.

What I did wrong? Should I have sent from the exchange to the segwit address, instead of the legacy one? I didnt sent to the segwit address, because I thought this address is only to witness transactions for the main address.

As i already mentioned previously, it doesn't matter which address you are sending TO. This doesn't make any difference in size.
It matters FROM which address you are sending.
legacy -> any_address = 'standard' fee
segwit -> any_address = lower fee due to lower tx size (weight).




SegWit got activated 23.08.2017.
But even if your wallet file was created before that date there won't be any problems with creating segwit addresses in an pre-segwit created wallet.
You are using the latest version of core, right?

Additionally you should still make backups. In case of anything not working you will always be able to restore your old wallet file.




Yes.

I use bitcoin-QT as wallet. If I move my wallet to another folder, QT creates a new wallet automatically when it starts. But this new wallet is always with a legacy address.

What I know is that you can create a segwit address using a legacy address. I did this in a empty wallet, just as a experiment, but when I tried a transaction from my main wallet to this empty wallet it had the same usual fees of legacy wallets.

However, I didnt create a segwit address in my main wallet, because I dont know if it is safe to generate those address in a wallet created in August 2017, that is, before the implementation of Segwit.

Should I send all the btc to the empty wallet, which have a segwit address, and only then, assumes that new transactions coming from this new wallet will be smaller?

It is irrelevant which address you are sending to.
If YOU are using a segwit address, your transactions will be lower in size (in comparison to sending from legacy).




The fee is usually being set as a rate (e.g. sat/B). As long as you send the same transaction (same amount of inputs/outputs - your wallet may have changed that),
the transaction size sent from a SegWit address will be lower than from a legacy address.




The easiest way of 'switching to SegWit' would be to simply send your whole balance to a (newly generated) SegWit wallet/address.
You don't have to first create another legacy wallet. That would just be an additional (unnecessary) transaction (incl. fees).
Just create a SegWit wallet and send your funds over. Depending on the amount of 'inputs' you have it might result in a pretty big TX (and high fees).
If you recieved a lot of small transactions, you might wait until the backlog of unconfirmed transactions has settled a bit (to not pay too much fees). [1]

[1] Currently 170k+ unconfirmed TX's (blockchain.info/unconfirmed-transactions) - Fee estimation: https://estimatefee.com/ and https://bitcoinfees.earn.com/

You don't need to send "SegWit" transactions to claim forked coins? What exactly are you trying to do?


Then something changed the DATA size of the transaction... or the "dynamic" fee rates changed. Generally, identical transactions (same number of inputs/outputs) being sent from a legacy address, should result in the same data size and same fee, regardless of the address types being sent to.


Depends on your wallet. Some wallet software let you create SegWit addresses in exiting wallet files... some wallet software requires you create a completely new SegWit only wallet file.

If I create a new wallet, and send a segwit transaction there (for example, to claim forked coins), which wallet need to have a segwit address (starting with 3), the one which is sending the bitcoin, or the one which is receiving it?

I tried to send to another wallet with a segwit address, but the fee was even higher than to a normal address. The recipient was a segwit address, the sender was legacy. The normal address on the recipient was asking standard fees.

My current wallet holding bitcoins is from august 2017, before segwit locked in. Should I make another legacy wallet, send a legacy transaction there, and only then create a third wallet which would be segwit?

Or can my current wallet, which was created before the lock-in, generate a segwit address (starting with 3), and then send to a legacy address in a second wallet, which would not have any segwit address?

Segwit basically does one thing: It removes redundant data from the transaction, and therefore lowers the size.
You have the choice between native segwit (bech32, starting with bc1...) and P2WPKH nested into P2SH (starting with 3... ).
Legacy addresses are the 'original' addresses which were introduced first (starting with 1..).
P2WPKH/P2SH addresses have the advantage of lowering transaction size ~30% (compared to legacy).
Bech32 transations are even smaller, but unfortunately a lot of online services don't accept these address type yet.

Some discussions about it happened here:https://bitcointalk.org/index.php?topic=2251039.0

I'm not sure what native segwit is, presumably that's just a pay-to-script transaction.
Legacy is the "original" transaction protocol. Segwit was set in place to reduce the demand on the network which is normally an address beginning with a 3 or a bech address (represented differently, normally with bv1 at the start).

Onto transaction times: both will confirm in the same amount of time for a specific fee (the legacy transaction fee will be higher). As a segwit transaction is slightly smaller, a lower fee can be paid and smaller transactions might fit into a block better than larger ones.

As the title says, what is the difference between them and which one is better to use for making each incoming and outcoming transaction confirmation faster?