Why Bitcoin Legacy Address got Replaced with Segwit

[JackMazzoni]

Why bitcoin legacy got replaced with segwit address. Is bitcoin legacy address not safe anymore?

[1714555588]

1714555588

[1714555588]

1714555588

[1714555588]

1714555588

[Charles-Tim]

P2PKH is not replaced because you can still use legacy addresses to make transaction.

With segwit, you can get about 42% to 52% fee reduction while making transaction. With legacy address, there is nothing like virtual byte or weight because the actual byte is the virtual byte. But with segwit, there is virtual byte or weight that is lower than the actual size of a transaction. This makes the transaction fee to also to be lower.

https://learnmeabitcoin.com/technical/transaction-weight
https://river.com/learn/terms/b/block-weight/

[hosseinimr93]

As mentioned above, with using segwit addresses, you can pay lower fees for your transactions, but it may worth mentioning that the fee reduction was not the main reason of segwit introduction.
Segwit was introduced to solve transaction malleability problem.

[JackMazzoni]

As mentioned above, with using segwit addresses, you can pay lower fees for your transactions, but it may worth mentioning that the fee reduction was not the main reason of segwit introduction.
Segwit was introduced to solve transaction malleability problem.

What is transaction malleability problem?

[hosseinimr93]

What is transaction malleability problem?

Transaction malleability is a bug which allows anyone to change the (unconfirmed) transaction, so that the transaction hash is changed without invalidating the signature and without invalidating the transaction.
This can't be done if all inputs of the transaction are native segwit.

[Yamane_Keto]

Legacy Address is still gaining importance in message signing, as there is no agreed upon standard for segwit signatures, so it is better to use Legacy Address if you want to sign a message. bc1 native segwit has become the default option due to saving fees.

[Charles-Tim]

Legacy Address is still gaining importance in message signing, as there is no agreed upon standard for segwit signatures, so it is better to use Legacy Address if you want to sign a message. bc1 native segwit has become the default option due to saving fees.

This thread is old and started before segwit was implemented and people on this forum were using legacy address to sign a message, but if you go to the recent pages, segwit addresses are used to sign message.

I have not used a legacy address to sign a message before.

So way importance is legacy address having in signing of message?

I can sign a message on these wallets: Electrum (desktop), Bluewallet, Sparrow and Samourai. Also wallets like Bitcoin Core and Specter can be used to sign message. The first noncustodial wallet which is now close source and not recommended anymore, Coinomi support signing of message.

[Catenaccio]

Use this Transaction fee calculation tool will help to understand why Nested Segwit, Native Segwit were created. Taproot is another type of Native Segwit (bech32) address. With Taproot address, it will be bech32m, starts with bc1p. Bech32 address starts with bc1q.

https://bitcoinops.org/en/tools/calc-size/
https://jlopp.github.io/bitcoin-transaction-size-calculator/

In the tool, you can choose transaction type.

Legacy address: P2PKH transaction type
Nested SegWit address: P2SH transaction type
Native Segwit address: P2WPKH and P2WSH transaction type
Taproot address: P2TR transaction type

Bech32 adoption

[hosseinimr93]

Legacy Address is still gaining importance in message signing, as there is no agreed upon standard for segwit signatures, so it is better to use Legacy Address if you want to sign a message. bc1 native segwit has become the default option due to saving fees.

This is not true.
You sign message with your private key, not with your address.

Look at the following example.

Private key:
L3Gif2E2Zdgc4kC47jLzpNtWvBLuE8rpSPowmYqZM2mC8Mjs8otT

Legacy address:
1Q4U4dfZJgBRqXrHAnv8FSCqKxzjqRJ4ca

Segwit address:
bc1qlnetknv5vza7vjakc22dkq895cczf4pkpkmcmm

Here is the message I just singed with the above private key:

Code:

This is my message.

And here is the signature.

Code:

IGflPCOgGqHfJ5Fb0q4AdTiFe1OZk8DNHGHitcfl7MtWWX9X/0GeBOec5OwZBl0cqV6/47Kt1scIS32BIzHU8HQ=

You can now use electrum and verify my message with both of above addresses.
If the tool you use doesn't allow signing message with a segwit address or it uses a different algorithm when signing/verifying message, the issue is related to the software.

[Charles-Tim]

You can now use electrum and verify my message with both of above addresses.
If the tool you use doesn't allow signing message with a segwit address or it uses a different algorithm when signing/verifying message, the issue is related to the software.

Exactly. What I think is that in the past when segwit was first adopted, some wallets do not support it. Also are those brain wallet and paper wallet signing and verifying message tools online which some people are using to sign and verify just legacy address messages and not supporting segwit addresses. Making them to think that segwit is not widely used. But all the wallet that are supporting message signing with bitcoin address that support native segwit or any other address type can be used to sign a message. Or if not all, all the ones that I have used sign and verify message for native segwit addresses, unless they are not supporting native segwit.

[pooya87]

What is transaction malleability problem?

Transaction malleability is a bug which allows anyone to change the (unconfirmed) transaction, so that the transaction hash is changed without invalidating the signature and without invalidating the transaction.
This can't be done if all inputs of the transaction are native segwit.

I wouldn't call it a bug since it affects unconfirmed transactions only and they are never considered safe to begin with so relying on their hash was never a thing! It only is an issue when it come to second layer (Lightning Network).

Additionally what you are describing is only one type of malleability that is done by third parties. Many of the ways to malleate a transaction have been prevented before with BIP62. SegWit fixed the rest involving the signature.
The other type that is still possible is when the owner of the key simply creates a different signature for the same transaction. That can never be prevented, nor does it need to be prevented.

[Yamane_Keto]

Legacy Address is still gaining importance in message signing, as there is no agreed upon standard for segwit signatures, so it is better to use Legacy Address if you want to sign a message. bc1 native segwit has become the default option due to saving fees.

This is not true.
You sign message with your private key, not with your address.

If the tool you use doesn't allow signing message with a segwit address or it uses a different algorithm when signing/verifying message, the issue is related to the software.

I did not say that you cannot sign a message using a segwit address, but I said that there is no unified standard for that, and if there is a point where Legacy Address VS Segwit excels, it would be this point, although I agree with you that it is laziness on the developers part.

[ABCbits]

What is transaction malleability problem?

Transaction malleability is a bug which allows anyone to change the (unconfirmed) transaction, so that the transaction hash is changed without invalidating the signature and without invalidating the transaction.
This can't be done if all inputs of the transaction are native segwit.

I wouldn't call it a bug since it affects unconfirmed transactions only and they are never considered safe to begin with so relying on their hash was never a thing! It only is an issue when it come to second layer (Lightning Network).

In past, it's also issue for those who use software which can't handle TXID change which result "multiple" deposit.

[arjunmujay]

Why bitcoin legacy got replaced with segwit address. Is bitcoin legacy address not safe anymore?

Why replaced to Segwit?
As far as I know, transaction fees and transaction time speed are the main points of the SegWit address.

Please note, by using SegWit:
1. ordinary transactions can be reduced by up to 50% compared to legacy.
For example, when making a transaction using a legacy address, it costs $10, and when using a SegWit address, it only costs $5.
2. transaction speed is faster than usual.
Transaction speed is much more efficient, from confirmations that take up to 10 minutes, can be reduced to only 1-2 minutes.

[Charles-Tim]

2. transaction speed is faster than usual.
Transaction speed is much more efficient, from confirmations that take up to 10 minutes, can be reduced to only 1-2 minutes.

This is not right, the transaction speed is still the same, but because of the fee which can be the same but make segwit transactions to have higher fee rate (sat/vbyte), that gives the transaction a higher priority for confirmation if compared with legacy address transactions.

[arjunmujay]

2. transaction speed is faster than usual.
Transaction speed is much more efficient, from confirmations that take up to 10 minutes, can be reduced to only 1-2 minutes.

This is not right, the transaction speed is still the same, but because of the fee which can be the same but make segwit transactions to have higher fee rate (sat/vbyte), that gives the transaction a higher priority for confirmation if compared with legacy address transactions.

Is that so?
I read in binance academy the transaction speed increase section, there it is explained that increasing transaction speed also affects transaction fees on the bitcoin network.
before segwit existed it could spend more than $30 per transaction, but after segwit appeared the cost became very low even $1 per transaction.

Therefore I estimate that every 10 minutes confirmation can be reduced to 1-2 minutes.
A Beginner’s Guide to Segregated Witness (SegWit)

[NotATether]

Is that so?
I read in binance academy the transaction speed increase section, there it is explained that increasing transaction speed also affects transaction fees on the bitcoin network.
before segwit existed it could spend more than $30 per transaction, but after segwit appeared the cost became very low even $1 per transaction.

Therefore I estimate that every 10 minutes confirmation can be reduced to 1-2 minutes.
A Beginner’s Guide to Segregated Witness (SegWit)

Actually that does not happen in practice because the miners just fill up their blocks with more transactions (the segwit kind) in that case.

If you filled a block with only legacy address transactions then it would have less transactions than a block which had only segwit address transactions.

But in practice, miners don't care what kind of address you have as long as you pay them a high enough fee. That's the only factor that determines confirmation times.

[hosseinimr93]

Is that so?

Yes, Charles-Tim is right.

Therefore I estimate that every 10 minutes confirmation can be reduced to 1-2 minutes.

No.
Bitcoin blocks are mined at the rate of 1 per ∼ 10 minutes on average.
If the fee you pay for your transaction is high enough, your transaction can be included in the next block. Whether you use legacy address or segwit address, you can't get confirmation before the next block is mined.

[Charles-Tim]

Is that so?
I read in binance academy the transaction speed increase section, there it is explained that increasing transaction speed also affects transaction fees on the bitcoin network.
before segwit existed it could spend more than $30 per transaction, but after segwit appeared the cost became very low even $1 per transaction.

Therefore I estimate that every 10 minutes confirmation can be reduced to 1-2 minutes.

Do not be confused to make wrong conclusion after reading.

Let us assume the mempool fee rate needed for high priority now is 31 sat/vbye.

If you use a fee rate of 20 sat/vbyte and the fee rate for high priority remained to be over 31 sat/vbyte for a long time, your transaction can not be confirmed. You transaction will be confirmed if the fee rate is reduced to or lower than 20 sat/vbyte.

If you use 35 sat/vbyte or higher as your transaction fee, and the fee rate for high priority did not increase more than 34 sat/vbyte before the next block is mined, your transaction will be confirmed in the next block.

Fee rate is proportional to fee.

Which means higher fee can actually make your transaction to be confirmed faster, if comparing it with low fee that is too low to get the transaction confirmed as fast as high fee.

Miners include transaction with higher fee rate into a block and it will be confirmed, leaving the lower fee rate aside until the mempool to become less congested.

[mocacinno]

I'm rephrasing the stuff  Charles-Tim and hosseinimr93 have already said (they are both correct), but i tried to make it a bit "simpler"...

My simplification is a bit "over the top", some aspects are oversimplified, but i'm trying to give an ELI13 explanation here

The bitcoin network re-adjusts the difficulty every 2016 blocks to make sure that, on average, one block gets found every 10 minutes. That's about ~6 blocks per hour. It doesn't matter if the hashrate climbs or plummets, the network re-adjusts every ~2 weeks to make sure that on average ~6 blocks are found per hour.

A block can only contain 1 Mb of transaction data, NOT including the witness data of a segwit transaction... A block can contain up to 4 Mb of data, but the first Mb is the "actual" transaction data, and the other 3 Mb is only witness data of segwit transaction. This means that only ~6 Mb of "actual" transaction data (not including witness data) can be added to the blockchain each hour. This is also the reason that, when the mempool is overflowing as it is now, a miner has a choice to optimize the block he/she is trying to solve... He/she can make any combination of unconfirmed transaction he/she wishes.

When people use legacy addresses, the complete transaction has to fit into the first Mb of the block. When people use segwit addresses, only a part of the transaction has to fit into the first Mb, and a big chunk of the transaction data can fit in the "extra" 3Mb. The first Mb is the actual bottleneck, a miner cares less about the witness data since he has 3Mb of blockspace to store said data.

Any transaction has a number of inputs (with a value) and a number of outputs (with a value). A miner solving a block can send the block reward to himself, but he can also add the sum of all the values of all inputs of all transactions in his block minus the sum of all the values of all the outputs of all transactions in his block to said block reward... SOOOOO for a miner, if there are plenty of transactions in the mempool to pick from, it's financially beneficial to add transactions with the highest fee per byte of transaction data (since the total size of the block is a limiting factor). Since a segwit transaction NOT including the witness data is much smaller than a legacy transaction, it needs less fee in order to become interesting for a miner to be added to the block he/she is trying to solve.

As soon as you get this, it's time to look at taproot