Difference between SegWit addresses

[Carlton Banks]

It's only the bc1 addresses that won't work backwards compatibly, and that's kind of irrelevant seeing as there aren't many wallets that use bc1 addresses.

Best advice is to use nested 3-starting addresses for Segwit now, because they're completely backwards compatible for all services and wallets. So there's no need to wait for others to wait to update, you can use Segwit now backwards compatibly.

You seem to confuse the meaning of backwards compatibility.
Bech32 addresses are backwards compatible.
This means:
- Transactions between legacy and bech32 addresses are compatible.
- "Old" nodes do "understand" those transactions from/to bech32 addresses
- There aren't any (network-)problems with bech32.

Wallets/Exchanges/Online service provider not accepting bech32 yet is due to not upgraded software (non-network related).
This has nothing to do with backwards compatibility. They just didn't update the software to accept those addresses.

Older software will refuse to send to bc1 addresses, as a basic error-checking measure.

I heard that coinbase, an exchange that I use when I need to cash out some coins, is finally going to update to segwit. I have no idea what type of addresses they will be using. But since they are updating to segwit, does this mean that even if they use the P2SH I will be able to make transfer to them if I use the bech32 addresses from electrum?

You can send from P2SH segwit or bech32/bc1 addresses now. It's sending to segwit addresses from non-upgraded exchanges that's the issue.

[1714047904]

1714047904

[bob123]

You can send from P2SH segwit or bech32/bc1 addresses now. It's sending to segwit addresses from non-upgraded exchanges that's the issue.

Thats basically exactly what i've said.

But since they are updating to segwit, does this mean that even if they use the P2SH I will be able to make transfer to them if I use the bech32 addresses from electrum?

You will always be able to send to any address from your bech32-type-address.
You will also always be able to receive funds to your bech32 address.

There only a problem occurs when you have to enter your btc-address anywhere to receive funds. Most websites/wallets hasn't been updated to regard bc1.. addresses as bitcoin addresses.
Network-wise everything is fine. Its just the websites/wallets software which needs an update.

[utdrmac]

I keep seeing things like "SegWit addresses are lower tx fees". Can someone explain why/how that is? Why does sending BTC to address A (old style) vs address B (SegWit style) incur higher tx fees? Aren't both transactions going on to the same blockchain and being processed by the same miners to be added to the same block?

[Xynerise]

I keep seeing things like "SegWit addresses are lower tx fees". Can someone explain why/how that is?

For you to understand that you need to understand how bitcoin transactions and fees work.
Bitcoin transactions are just inputs and outputs. Whenever you make a bitcoin transaction you reference old unspent outputs which form your inputs and create new outputs for the recepient to spend.
Bitcoin transaction fees are denominated in satoshis per byte, which is the size of the transaction in bytes.
In a transaction inputs make up most of the transaction: in a standard transaction with one input and 2 outputs inputs take up about 65% of the transaction, and in the input the signature takes up 60% of the space.
So to recap so far in a bitcoin transaction we have inputs and outputs: inputs reference where the bitcoin is coming from, and outputs state where they're going to.
Inputs have ~70% of a transaction, and signatures in inputs take up ~60% of the input.
Signatures are only needed for validation yet they take up most of the space and you can't remove signatures because they are needed to prove said person has permission to move the bitcoin, but you can move them elsewhere, which is what segwit does.
It moves the signature to "witness" portion which doesn't count in transaction size so the transaction size becomes smaller and thus the fees are smaller.


 

Why does sending BTC to address A (old style) vs address B (SegWit style) incur higher tx fees?

Sending TO a segwit (P2PWKH-P2SH or Bech32) address or a legacy address (P2PKH or P2SH) has nothing to do with transaction fees.
Like I said above its the inputs that dictate the size of the transaction so no matter the type of address you're sending TO, it won't affect the size of the transaction and hence the fees.

However sending "FROM" a segwit address incurs less fees because transactions are smaller.

[utdrmac]

Awesome answer! Thanks! Had no idea inputs & signatures took up 70% of the transaction.

[bitmover]

Recently I discovered that you cannot sign messages in SegWit address...
Technically you can sign, but it cannot be verified.

Some wallets, like ledger, let you sign. But they will sign with a Legacy address, even if you are using a SegWit wallet. Really weird.

I even started a discussion about this
https://bitcointalk.org/index.php?topic=2885058

For me this is a serious matter because I will lose many airdrops =/

[Xynerise]

Recently I discovered that you cannot sign messages in SegWit address...
Technically you can sign, but it cannot be verified.

I even started a discussion about this
https://bitcointalk.org/index.php?topic=2885058

For me this is a serious matter because I will lose many airdrops =/

They are working on it.
There is already a draft BIP foto a standard for message signing
 - https://github.com/brianddk/bips/blob/legacysignverify/bip-0xyz.mediawiki

[bitmover]

They are working on it.
There is already a draft BIP foto a standard for message signing
 - https://github.com/brianddk/bips/blob/legacysignverify/bip-0xyz.mediawiki

Yeah, I learned about that, so I decided to keep my segwit wallet... i hope they solve this soon!
Anyway, it´s important that people know about this limitation before creating a segwit wallet and transfer their funds.

[Rath_]

Recently I discovered that you cannot sign messages in SegWit address...
Technically you can sign, but it cannot be verified.

Some wallets, like ledger, let you sign. But they will sign with a Legacy address, even if you are using a SegWit wallet. Really weird.

I even started a discussion about this
https://bitcointalk.org/index.php?topic=2885058

For me this is a serious matter because I will lose many airdrops =/

As far as I know, the only wallets that support signing messages with a SegWit address are Trezor (beta wallet) and Electrum. I have already tried many websites which were supposed to verify the message and unfortunately, all failed. I only managed to verify messages signed with a SegWit address using Electrum but I don't have my Trezor yet to test whether or not there are any problems or differences between them. It looks like many people will be confused while verifying messages unless someone creates a standard which could be implemented everywhere.

[classicsucks]

Recently I discovered that you cannot sign messages in SegWit address...
Technically you can sign, but it cannot be verified.

Some wallets, like ledger, let you sign. But they will sign with a Legacy address, even if you are using a SegWit wallet. Really weird.

I even started a discussion about this
https://bitcointalk.org/index.php?topic=2885058

For me this is a serious matter because I will lose many airdrops =/

Jesus. Just another reason to stay off of Segwit.

If this is correct, 25% of all BTC that has circulated since the Segwit fork don't exist on the new BTC forks. Honestly, I suppose this would increase the scarcity and thus the value or forked coins. But anyone using Segwit is screwed out of their shares!

[HCP]

Jesus. Just another reason to stay off of Segwit.

If this is correct, 25% of all BTC that has circulated since the Segwit fork don't exist on the new BTC forks. Honestly, I suppose this would increase the scarcity and thus the value or forked coins. But anyone using Segwit is screwed out of their shares!

Oh no... screwed out of $10 worth of ShitCoin™ that I can't even sell because no reputable exchange has it listed...

In any case, if the fork happens to support SegWit (which several have)... you are not in any danger of missing out... The post that you quoted was referring to "airdrops" that require you to sign messages from a bitcoin address.

As far as I know, the only wallets that support signing messages with a SegWit address are Trezor (beta wallet) and Electrum. I have already tried many websites which were supposed to verify the message and unfortunately, all failed. I only managed to verify messages signed with a SegWit address using Electrum but I don't have my Trezor yet to test whether or not there are any problems or differences between them. It looks like many people will be confused while verifying messages unless someone creates a standard which could be implemented everywhere.

I just tried to sign a test message with both Electrum and with Trezor (same address, same message)... Electrum generated a signature as:

IGUjYV7hZ6ZZeKrW/glIUKTeFOpCYnKmMTXjXG38oROWIlbCaoam/o8OzDlzoHuddj4UDvSjfYllDVE0KQ4i8Hk=

However, Trezor generated the signature as:

JGUjYV7hZ6ZZeKrW/glIUKTeFOpCYnKmMTXjXG38oROWIlbCaoam/o8OzDlzoHuddj4UDvSjfYllDVE0KQ4i8Hk=

1 letter different... otherwise, the signatures were identical!!?!  Obviously, the two wallets are unable to properly verify the message from the other due to the difference in the signatures.

This issue on the Electrum github (https://github.com/spesmilo/electrum/issues/3861) shows the current state of affairs... basically, no consensus... but it is being worked on.

[Kakmakr]

Recently I discovered that you cannot sign messages in SegWit address...
Technically you can sign, but it cannot be verified.

Some wallets, like ledger, let you sign. But they will sign with a Legacy address, even if you are using a SegWit wallet. Really weird.

I even started a discussion about this
https://bitcointalk.org/index.php?topic=2885058

For me this is a serious matter because I will lose many airdrops =/

Jesus. Just another reason to stay off of Segwit.

If this is correct, 25% of all BTC that has circulated since the Segwit fork don't exist on the new BTC forks. Honestly, I suppose this would increase the scarcity and thus the value or forked coins. But anyone using Segwit is screwed out of their shares!

This is wrong. SegWit addresses can be signed. The problem come in with different wallet providers that are using different formats of SegWit and tools to verify the signatures. Example : A few days ago, I signed an address with my Ledger and they use Nested Segwit (starting with 3).

The other person used a tool provided by Brainwallet that verify bech32 addresses (starting with bc1) and he could not verify that.

This is causing a lot of confusion and frustration, but hopefully things will sort themselves out as adoption of the technology increase and some kind of standard are chosen or more tools with more formats are developed.

[bitmover]

Recently I discovered that you cannot sign messages in SegWit address...
Technically you can sign, but it cannot be verified.

Some wallets, like ledger, let you sign. But they will sign with a Legacy address, even if you are using a SegWit wallet. Really weird.

I even started a discussion about this
https://bitcointalk.org/index.php?topic=2885058

For me this is a serious matter because I will lose many airdrops =/

Jesus. Just another reason to stay off of Segwit.

If this is correct, 25% of all BTC that has circulated since the Segwit fork don't exist on the new BTC forks. Honestly, I suppose this would increase the scarcity and thus the value or forked coins. But anyone using Segwit is screwed out of their shares!

This is wrong. SegWit addresses can be signed. The problem come in with different wallet providers that are using different formats of SegWit and tools to verify the signatures. Example : A few days ago, I signed an address with my Ledger and they use Nested Segwit (starting with 3).

The other person used a tool provided by Brainwallet that verify bech32 addresses (starting with bc1) and he could not verify that.

This is causing a lot of confusion and frustration, but hopefully things will sort themselves out as adoption of the technology increase and some kind of standard are chosen or more tools with more formats are developed.

Hello.
The problem is that those signatures and verifications are nonstandard. Core can't verify.

In ledger nano case if you look closely you will notice that the signature you made was done not by your segwit address, but for it's legacy counterpart.

If you look closely you will find that legacy address and that signature (made by the segwit) will be verified on brainwallet with that Legacy.

This is an known issue, and not ledger fault, but lack of standard.

[classicsucks]

Jesus. Just another reason to stay off of Segwit.

If this is correct, 25% of all BTC that has circulated since the Segwit fork don't exist on the new BTC forks. Honestly, I suppose this would increase the scarcity and thus the value or forked coins. But anyone using Segwit is screwed out of their shares!

Oh no... screwed out of $10 worth of ShitCoin™ that I can't even sell because no reputable exchange has it listed...

In any case, if the fork happens to support SegWit (which several have)... you are not in any danger of missing out... The post that you quoted was referring to "airdrops" that require you to sign messages from a bitcoin address.

Yeah well I just sold another $250 worth of airdrop to some simp, but you should go ahead and keep pumping all of your BTC to those Segwit addresses... you're getting me a better price!

[Xynerise]

I keep seeing things like "SegWit addresses are lower tx fees". Can someone explain why/how that is? Why does sending BTC to address A (old style) vs address B (SegWit style) incur higher tx fees? Aren't both transactions going on to the same blockchain and being processed by the same miners to be added to the same block?

I've explained it before on this thread.
Check this link: https://bitcointalk.org/index.php?topic=2347427.msg30732685#msg30732685

[bob123]

I keep seeing things like "SegWit addresses are lower tx fees". Can someone explain why/how that is?

SegWit transactions are smaller in size. SegWit basically 'removes redundant data' from the transactions.
This makes them smaller in size -> lower fees to pay (with same fee rate (sat/B)).

Why does sending BTC to address A (old style) vs address B (SegWit style) incur higher tx fees?

It doesn't.
Its sending FROM SegWit which leads transactions to be smaller in size. The output of the TX (which address type) doesn't matter.

Aren't both transactions going on to the same blockchain and being processed by the same miners to be added to the same block?

They are. Its the size which matters.
Even though the sat/B rate is the same you will pay lower fees in total because of the smaller size.

[Carlton Banks]

I keep seeing things like "SegWit addresses are lower tx fees". Can someone explain why/how that is?

SegWit transactions are smaller in size. SegWit basically 'removes redundant data' from the transactions.
This makes them smaller in size -> lower fees to pay (with same fee rate (sat/B)).

Not really.

Segwit transactions are either 10% smaller (native bc1 type addresses) or 15% larger (nested P2SH addresses for backward compatibility). Assuming everyone used bc1 addresess for payments, a 10% improvement in space efficiency couldn't increase blocks from 1MB max to the 2.2MB blocks that Segwit has thus far made possible.


What makes the difference is the re-structuring of transaction data within the Segwit blocks the network now uses. Signatures have been changed in a way that prevents a specific Denial of Service attack (a sighash based attack). This change was deemed by the designers of Segwit to allow blocks of up to 4MB to be safely accepted on the Bitcoin network. As part of the Segwit changes, transaction data & their signatures are priced separately, whereas they were both priced together before Segwit. Signature data is discounted, and that's why Segwit transactions are cheaper.

[qwerty10111]

Hi there, recently I found this website:

https://segwitchecker.com

Hope this might be helpful for you, guys.

[Xynerise]

Hi there, recently I found this website:

https://segwitchecker.com

Hope this might be helpful for you, guys.

For most Bitcoin addresses their difference is cosmetic: P2PKH (addresses that start with 1) are definitely not Segwit addresses; P2PWPKH addresses (Bech 32 addresses, that start with bc1) are obviously segwit addresses.
The only confusion is in P2SH addresses (those that start with 3), they could be normal P2SH addresses (multisig, usually), or P2WPKH wrapped in P2SH (Segwit addresses).
However the only way to distinguish between them is only when the UTXO is spent, and the redeem script exposed.
Until then it is impossible to distinguish between them.

[BanishedDemon]

I keep seeing things like "SegWit addresses are lower tx fees". Can someone explain why/how that is? Why does sending BTC to address A (old style) vs address B (SegWit style) incur higher tx fees? Aren't both transactions going on to the same blockchain and being processed by the same miners to be added to the same block?

Allow us to do a brief contrast to see how an awful lot rate you can save through the usage of segwit pockets. For everyday bitcoin transactions, the concern depends on price/(tx length). For segwit, a brand new concept called weight become introduced, so what topics now could be fee / (digital size) .



The above shows the digital length of various sorts of bitcoin transaction. i have referred to usually used one entry, two output transactions for numerous types. right here are the transaction ids for reference — regular, Segwit in P2SH, native Segwit. As you may see you can get a cool 38% discount the usage of native segwit !! using segwit wallets in truth has a two effect:

   -You keep on transaction fees
   -You transaction is smaller taking less space. This allows greater transactions to get into blocks. This reduces mempool congestion and decreases the common transaction price,    because you are now competing with less unconfirmed tx to get into blocks.