My 2 big reasons why we should use SegWit addresses instead of Legacy addresses

[Phu Juck]

SegWit (Segregated Witness) was introduced in 2017 for Bitcoin. It was activated as a soft fork according to Bitcoin Improvement Proposal 148 (BIP 148), which enforced SegWit to be activated. SegWit aimed to improve scalability, reduce transaction fees, and fix transaction malleability issues, in addition to more smaller benefits.

Let’s have a look today at why SegWit is a good update for Bitcoin because Segregated Witness (SegWit) addresses for Bitcoin are offering several advantages over legacy addresses:


Native and nested SegWit

Today, we know about native and nested SegWit addresses. While nested SegWit only offers few advantages, native SegWit is what was introduced in 2017, giving us full benefits from SegWit transactions:

________	__________________________	_______________________________________________________________________________ _____________________
1…	Legacy-Address	P2PKH (pay to public key hash)
3…	Multisignature-Address	P2SH (pay to script hash)
________	__________________________	_______________________________________________________________________________ _____________________
3…	nested SegWit-Address	P2WPKH-P2SH (pay to witness public key hash - pay to script hash) / P2WSH-P2SH (pay to witness script hash - pay to script hash)
________	__________________________	_______________________________________________________________________________ _____________________
bc1q…	native SegWit-Address (bech32)	P2WPKH-bech32 (pay to witness public key hash) / P2WSH-bech32 (pay to witness script hash)
bc1p…	Taproot-Address	P2TR-bech32m (pay to tap root)

1. SegWit transaction are cheapest

SegWit offers us compared to Legacy or nested SegWit really low transaction fees and it will reduce our costs paid for transaction fees a lot.
Here's an overview how large transactions of each type are:  

Type	|Input  vbyte	|Output vbyte	|transaction vbyte
Taproot	|57,5	|43	|111
Native SegWit	|68	|31	|109.5
Nested SegWit	|93	|32	|134
Legacy	|140	|34	|192

For each input, we will save additional transaction fees.

SegWit transactions are simply smaller in size compared to legacy transactions because all witness data (signatures) is separated from transaction data. As a result, we get a lower fee per transaction vbyte.




2. Increased Block Capacity

Bitcoin has a limit of transactions in terms of transaction size for each Block: a limited number of transactions can only be fitted into each Bitcoin block, limiting Bitcoin’s capacity in terms of  transaction size per new block.  
SegWit allows more transactions to be fitted into each block. By separating all witness data, SegWit effectively decreases size limits for each transaction and effectively increases Bitcoin’s block size limit, which helps to process more transactions per block.  
So, SegWit actively helps to reduce congestion in Bitcoin’s mempool.

Overall, using SegWit addresses will help us to reduce transaction costs, have a better network performance and future-proofing for additional improvements and features for Bitcoin.


Which ones are your favorite reasons to use Bitcoin native SegWit addresses?


Sources

Pay-to-taproot (P2TR) transaction fee
Why people should be using SegWit addresses
Minimizing bitcoin transaction fee
Mempool empty! Use this opportunity to Consolidate your small inputs!
List of Bitcoin Mempool Viewers for Reference

[Charles-Tim]

Here’s an overview how large transactions of each type are: 

Type	|Input  vbyte	|Output vbyte	|transaction vbyte
Taproot	|57,5	|43	|111
Native SegWit	|68	|31	|109.5
Nested SegWit	|93	|32	|134
Nested SegWit	|140	|34	|192

For each input, we will save additional transaction fees.

You mean legacy address where I bold.

Most wallets as of today are using native segwit as the default which makes native segwit transaction make up more than 95% of the total bitcoin transaction. Those exchanges are the ones that are still making use of legacy addresses the most.

[Phu Juck]

Here’s an overview how large transactions of each type are: 

Type	|Input  vbyte	|Output vbyte	|transaction vbyte
Taproot	|57,5	|43	|111
Native SegWit	|68	|31	|109.5
Nested SegWit	|93	|32	|134
Nested SegWit	|140	|34	|192

For each input, we will save additional transaction fees.

You mean legacy address where I bold.

You are right, it needs to say "Legacy Address", I've edited it now.

Most wallets as of today are using native segwit as the default which makes native segwit transaction make up more than 95% of the total bitcoin transaction. Those exchanges are the ones that are still making use of legacy addresses the most.

It is a big pity we still have exchanges using such outdated address types

[Mia Chloe]

~snip

I've seen a very similar thread by a reputable user here I think 1miau back when I was still a newbie. Anyways for me actually the best part about using Bitcoin native SegWit addresses really boils down to two things;

First off, it's all about those lower transaction fees. Nobody likes paying more than they have to. With native SegWit, your transactions are just inherently smaller because of how they're built and that means you pay less in fees. It’s a pretty sweet deal especially when the network gets busy.

And then there's the speed. Because these smaller transactions can fit more easily into each Bitcoin block it essentially makes the network more efficient meaning your transactions get confirmed faster which is super helpful when you're waiting for a payment to go through or a trade to clear.

[franky1]

real data wise there is not much difference between legacy vs segwit..
the reason transactions are TREATED as cheaper, is a form of miscounting actual bytes.. basically a false economy to entice people to use a new thing even if the benefits are tweaked/misrepresented

also back in legacy days pre segwit transactions were averaging 2000tx and had potential of 4200tx a block.. now fast forward.. we have segwit allowing all this crap meme bloat junk thats not validated. not lean, and not helping increase the tx count.. we are not averaging 8k-16k tx, not even close

id rather use keys where the system does actually count every byte and validate every byte.. you know good code

once you realise certain opcodes can be used by wallets to have multiple paths of signing, where even you wont know what type of signature is needed to spend later.. your funds can be at risk unless you are checking every transaction you make or receive at the raw data level, your you manually created the public address  so if you are unsure, just go with the battle tested key formats that just do the job as promised.. (and thats why exchanges with many employee's involved stick with legacy)

just remember, core devs MADE legacy more expensive via bad code in the fee estimate math.. and they can do the same with segwit
if we just asked devs to put their politics aside and wrote neat clean code that actually counts bytes, everyone can pay equally
legacy is not expensive due to a flaw. segwit is only discounted because devs decided to discount segwit.. but that discount can end with a few lines of code

instead of trying to get people to shift to segwit. we should be demanding core devs get off their high horse government status of control. and instead make some clean code that actually counts all bytes, validates all bytes and not be so cludgy and patchy. then we can all enjoy a better more appropriate system, insted of this game they are playing.
imagine an actual 4mb block thats actually counting bytes and allowing actual legacy transactions to use the entire 4mb space. it means more transactions per block and less dead data thats disregarded, less not counted data, less not validated data..
..you know good security

[takuma sato]

I've read some theories defended by some people that claim Legacy addresses contain the maximum amount of information in regards to possibility of reversing them. In theory, if enough miners colluded they could "reverse" (in simple terms) SegWit addresses but not Legacy addresses. This may be some fringe chance that it happens and probably not practical to worry about it, but the real paranoid may benefit from continue to using legacy addresses at the expense of paying more fees.

[Charles-Tim]

I've read some theories defended by some people that claim Legacy addresses contain the maximum amount of information in regards to possibility of reversing them. In theory, if enough miners colluded they could "reverse" (in simple terms) SegWit addresses but not Legacy addresses. This may be some fringe chance that it happens and probably not practical to worry about it, but the real paranoid may benefit from continue to using legacy addresses at the expense of paying more fees.

You mean the transaction? The issue with legacy address was the transaction malleability in which the txid of a transaction can be altered but the transaction itself is not reversed.

What that can lead to transaction to he reversed is chain reorg and 51% attack but which can affect any address type. Chain reorg may be of no issue because the transactions that was added to the stale block will likely be contained in the block that has the longest chain. And transactions that are not there will likely be later confirmed later in another block. But the problem is that the transaction may have low fee and if the mempool become congested like immediately and for long, the transaction may later be dropped from the mempool in a way the sender can double spend it. This is not about the address someone is using.

[mitzi65jason]

I've read some theories defended by some people that claim Legacy addresses contain the maximum amount of information in regards to possibility of reversing them. In theory, if enough miners colluded they could "reverse" (in simple terms) SegWit addresses but not Legacy addresses. This may be some fringe chance that it happens and probably not practical to worry about it, but the real paranoid may benefit from continue to using legacy addresses at the expense of paying more fees hmh smart square

You mean the transaction? The issue with legacy address was the transaction malleability in which the txid of a transaction can be altered but the transaction itself is not reversed.

What that can lead to transaction to he reversed is chain reorg and 51% attack but which can affect any address type. Chain reorg may be of no issue because the transactions that was added to the stale block will likely be contained in the block that has the longest chain. And transactions that are not there will likely be later confirmed later in another block. But the problem is that the transaction may have low fee and if the mempool become congested like immediately and for long, the transaction may later be dropped from the mempool in a way the sender can double spend it. This is not about the address someone is using.

Thanks for the info I will try to figure it out for more.

[DubemIfedigbo001]

Segwit, mostly native segwit offers a better compatibility across exchanges. Most exchanges have adopted it because of its speed and lower transaction costs. I was disappointed to see that Bitget still uses legacy address as its only supported address for bitcoin deposits. They are really backward with technology.

Taproot is the most recent innovation, although its usage is still growing, but its features are noteworthy:
- Introduced in late 2021 as part of a major upgrade to enhance privacy and scalability.
- Supports complex multi-signature transactions that appear as ordinary transactions, improving privacy.
- Uses the Bech32m encoding scheme for better efficiency.

https://crypto-corner.com/2024/09/30/legacy-native-segwit-nested-segwit-taproot-bitcoin-wallet-addresses-explained/#:~:text=The%20primary%20Bitcoin%20address%20formats%20are%3A%20Legacy%2C%20Nested,protocol%20%28a.k.a.%20forks%29%20that%20have%20occurred%20over%20time.

Earlier, maybe a year or so ago, Binance supported Taproot, but I cannot see it in the networks recently, maybe they suspended support for it. I don't know if anyone noticed too

[pooya87]

It was activated as a soft fork according to Bitcoin Improvement Proposal 148 (BIP 148), which enforced SegWit to be activated.

SegWit BIPs are 141 and 143 and it got activated like any other soft-fork through BIP-9.
BIP148 is actually more of a malicious attack on Bitcoin's principles. Nobody should not ever be allowed to "force" activation of any change without reaching majority's support. An important part that is missing from that BIP which is why I categorize it as a malicious attack.

SegWit transactions are simply smaller in size compared to legacy transactions because all witness data (signatures) is separated from transaction data. As a result, we get a lower fee per transaction vbyte.

I can't believe these two mistakes are still being repeated 7 years after activation of SegWit!!

SegWit transactions have lower weight compared to legacy, they are not smaller in size.
Also the witness data is NOT "separated" from transaction data. It is still a part of it like any other part like version, locktime, etc. It is just placed in a new location before the locktime in the serialization of transactions.

The reason why you end up paying a lower fee despite having bigger raw byte size is because fee calculation changed to be based on weight and virtual size.

By separating all witness data, SegWit effectively decreases size limits for each transaction and effectively increases Bitcoin’s block size limit, which helps to process more transactions per block.

Same mistake again.
The witness is still part of the transaction but because older nodes see SegWit output scripts as a script that anyone can spend, they don't need to see the signature. So it can be stripped only when the block is being sent to the old nodes which no longer fully verify everything.
This way the capacity is increased in a backward compatible way.

You see the problem with saying "witness is separated" is that next someone is going to ask "where does it go" and "why can't I spend anyone else's coins if signatures are separated from transactions".

[satscraper]

While the elevated transaction fees are undoubtedly the key point that makes P2PKH addresses less appealing in use, there’s another often overlooked issue i.e. they are case sensitive, meaning that even a small change in address ^{for instance the use of the lower case for single character instead of the upper case or vice versa} results in a completely different address. Thus, using them users are more likely to make fatal mistakes especially at their listening comprehension.

[igor72]

While the elevated transaction fees are undoubtedly the key point that makes P2PKH addresses less appealing in use, there’s another often overlooked issue i.e. they are case sensitive, meaning that even a small change in address ^{for instance the use of the lower case for single character instead of the upper case or vice versa} results in a completely different address. Thus, using them users are more likely to make fatal mistakes especially at their listening comprehension.

In this case the address will be invalid, you can't send to it.

[satscraper]

While the elevated transaction fees are undoubtedly the key point that makes P2PKH addresses less appealing in use, there’s another often overlooked issue i.e. they are case sensitive, meaning that even a small change in address ^{for instance the use of the lower case for single character instead of the upper case or vice versa} results in a completely different address. Thus, using them users are more likely to make fatal mistakes especially at their listening comprehension.

In this case the address will be invalid, you can't send to it.

Who knows... it's never 100% guaranteed. Some of these addresses might be valid meaning that if you send funds to them the client validates the relevant checksum and they're likely gone for good from sending wallet. The sender loses the money and the receiver ^{whoever controls that address} gets the surprise ^{in the form of bitcoins} "out of nowhere".BTW, these kinds of "surprise" may happen due to simple typos when someone manually enters the wallet address.

[igor72]

Who knows... it's never 100% guaranteed. Some of these addresses might be valid meaning that if you send funds to them the client validates the relevant checksum and they're likely gone for good from sending wallet.

A bitcoin address contains 32 bits of the checksum, so the probability of the case you describe is 1/(2³²). This is a very small number, practically can be neglected.

[satscraper]

Who knows... it's never 100% guaranteed. Some of these addresses might be valid meaning that if you send funds to them the client validates the relevant checksum and they're likely gone for good from sending wallet.

A bitcoin address contains 32 bits of the checksum, so the probability of the case you describe is 1/(2³²). This is a very small number, practically can be neglected.

I'm aware of the math behind addresses. However, it still doesn’t equal zero. Also, transactions might be sent to incorrect address through clients or online services that ^{for whatever reason} don’t perform checksum validation. It’s always better to be safe than sorry an avoid the potential mistakes done on receiver's address that could cost you money. ^{Thanks for this opportunity to answer you} .

This is a very small number, practically can be neglected.

Regarding "very small number, practically can be neglected", the odds of you being born were even smaller, yet here you are, typing on this forum.

Be dismissive of the small numbers is the pretty bad practice.

[Phu Juck]

My topic is still relevant today, where many participants choose SegWit addresses instad of legacy addresses. SegWit is much cheaper and relieves Bitcoin's mempool quite a lot.

[BlackBoss_]

My topic is still relevant today, where many participants choose SegWit addresses instad of legacy addresses. SegWit is much cheaper and relieves Bitcoin's mempool quite a lot.

The adoption of Bitcoin Segwit has increased a lot in recent years and this chart shows this since May 2021. From about 45%, Legacy input transactions dropped to under 20% in January 2022. Then, it declined to about 6% in June 2023 and it has fluctuated around 6% since then.
https://mainnet.observer/charts/transactions-segwit-transition/

Another chart that shows Segwit adoption increase is this one https://mainnet.observer/charts/transactions-spending-segwit/