Topic: Difference between SegWit addresses - page 2. (Read 9578 times)

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.


 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.

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?

Thats basically exactly what i've said.




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.

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



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.

Are there any known reasons for the time it's taking for wallets to update their software in order prevent all these problems and confusions related to segwit? I was considering updating to segwit as well, but I'm delaying this step because I would like to use electrum, and from what I've read they use the bech32 addresses, but they seem to be the only ones doing it (maybe there are more, but definitely not the majority).

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

Nested Segwit (starting 3) will work anywhere, all wallet software understands it. 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. So it's all software related, so we just need to wait for wallets to be updated.

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.



No, Bitcoin Core 0.16 will be available something like next week, I would guess. It's the Segwit wallet release, and has been expedited a little.

Ok, I got it. I thought that was strange as well, since segwit came out of a soft fork, so I actually expected that the "old addresses" would still be compatible with the segwit ones, but I then heard things about those compatibility issues, and I wasn't fully understanding them. So it's all software related, so we just need to wait for wallets to be updated. I heard that the new version of Bitcoin Core wallet due to complete by May 1, should help solving these "problems".

Bech32-type addresses are more efficient, yes.
But you don't have any problems with sending/receiving to/from any address.
You can send/receive to/from any address you wish. Everything will work as before.

The problem with the slow adoption is that some wallets/exchanges/service provider won't allow you to enter a BTC address starting with bc1..
simply because they have a check-function to make sure you enter a "valid" btc address.
And as soon they check your address is neither starting with 1.. nor with 3.. they will give you an "wrong format" error.

This is just a problem of the exchanges/wallets/...
This has nothing to do with bitcoin/segwit itself.

I also have a question regrading segwit. Although I keep my "old" wallet with non segwit address, I've also created a new one that has native segwit addresses (the bech32 P2WPKH type, so addresses starting with bc1). I was aware that I would probably not be able to send or receive from non segwit addresses, but I decided to go for this option anyway, since I heard they are more efficient, so I preferred them over the "transitional" P2SH addresses.

My question is, will I be able to send/receive coins between my bech32 P2WPKH, and the P2SH addresses?

The thing is that segwit adoption is taking a lot of time, so I'm afraid that the "transitional" P2SH addresses get more "popular", and it will take a while for me to be able to really use my bech32 P2WPKH addresses.

Thanks.

Yes.

Yes.

Can I send bitcoins from a standard wallet (starting with 1, i.e: 1dr4Jindendl....) to a SegWith address starting with bc1?

If yes, can I do it on electrum?

Apparently, Electrum on purpose doesn't want to support 3-prefix P2SH SegWit addresses:
https://github.com/spesmilo/electrum/issues/3460

Samourai wallet is the best option to go. You can generate both normal and SegWit (with '3') addresses for receiving and you can also send to Bech32 addresses (bc1) or, you have Trezor too (If you want to invest in a hardware wallet).

so I created a new Segwit wallet with Electrum and the address start with "bc1"... since it's not widespread yet, can anyone recommend a Windows desktop (or Android) wallet who's addresses start with a "3" (since its kinda backward compatible?)

It's easy to loop through the calculation of the address until you match some vanity string but bear in mind it's only a BIP16 P2SH -looking address.
Only the creator of the address would know it's a segwit output until it is spent.

You may want to create a native BIP173 P2WPKH segwit address to make it obvious it's a segwit output from the start.
However BIP173 is only a draft afaik even if it is already supported by Electrum.

I'm not really familiar with Ruby but is it that easy to modify this to get the ability to generate SegWit vanity addresses?

For those interested in creating segwit outputs, I just posted a ruby script for building a P2SH-P2WPKH address and spending from it, as a gist:
https://gist.github.com/pierrenoizat/f082d62d49e49f81978b97ad5900789a