Topic: Should I make a legacy, segwit or native segwit wallet? (Electrum) (Read 231 times)

I'm struggling to envisage a situation where it would be.

Either the service would broadcast the transaction, in which case you would receive the coins in your address, or they wouldn't, in which case the coins would never leave the service. It would be possible, I suppose, that a particularly poorly set up service could debit the coins from your account with them, but then fail to make the transaction because their system didn't recognise a bc1 address. Since the coins never actually left their system in that case, and it was only the balance of your account with them which was updated, then they would be able to rectify this via contacting their support service.

The few times in the past I tried to withdraw to a bc1 address which a service didn't support, I was simply met with an "Invalid address" error or similar whenever I entered my address. I was never able to actually submit a withdrawal request or get anywhere near creating a transaction.

Is it possible that money could be lost if you try to withdraw to a bc1 address but the service doesn't support it?

Correct. There are no services which I know of (someone can correct me if I'm wrong, but I'm pretty sure I'm not) which won't let you withdraw coins to nested segwit "3" addresses.

Any service which you are trying to withdraw from, simply try to withdraw to a native segwit "bc1" address first. It will save you the most on fees going forward, and there is no restriction to what type of addresses services will receive funds from. If the service doesn't allow you to withdraw to a native segwit "bc1" address, then use a nested segwit "3" address instead.

From there, you can either move your coins from a "3" address to the "bc1" immediately, or (what I would probably do) is wait until you are going to spend these coins anyway, and redirect any change to a new "bc1" address rather than back to another "3" address.

Thanks o_e_l_e_o, now I have all three types of wallets. The legacy one shouldn't be necessary as all clients should be able to send to segwit (3) addresses, right?

we have been signing messages from P2PKH addresses for many years now and there hasn't been any standard for them either. BIP-137 was created on Feb. 2019!
considering the fact that extending the same code to be used for P2WPKH and P2SH/P2WPKH addresses is ridiculously easy, in my opinion the only reason why most clients don't yet support it is either because they have no knowledge of underlying cryptography (namely ECDSA) or are too lazy to do it.
bitcoin core hasn't yet done it either, so lazy ass developers have no code to copy from, whereas they had the code for P2PKH addresses to copy from!

The problem is that there is no set standard (yet) for signing messages from SegWit addresses in the same way as there is for P2PKH addresses. There are quite a few clients which will let you sign messages from SegWit addresses, but there is no guarantee that these messages will be verifiable in other clients. So if I've signed a message from a bech32 address in Electrum, for example, then you would also need to use Electrum to verify it, and you would have to trust that Electrum are using a safe and secure method.

That's why in the staking thread in the Meta board I've staked a legacy address, despite not using a legacy address for coins in over a year.

If you're interested, BIP 322 is a proposed solution for this issue: https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki

Yes. That's the only exception that I can think of. Basically for staked addresses[1] here on Bitcointalk; for changing addresses on campaigns and account recovery and such. Beyond that, I don't even know other services outside Bitcointalk that requires signing of messages.

---

[1] https://bitcointalksearch.org/topic/stake-your-bitcoin-address-here-996318

Some services or people want you to only use addresses you can sign messages from. Unfortunately you can't sign messages from segwit addresses in most(all?) wallets as of now.

Why though? There's almost no reason to use legacy addresses now besides a few exceptions. It's not like SegWit addresses are harder to use, as the user experience pretty much the same. And who doesn't like cheaper transaction fees?

I've heard of the days when blockchain.com (formerly Blockchain.info) wallet didn't allow you to send to SegWit addresses starting with bc1 as they were not recognized then, so I stopped using their wallet. Then, I went for Electrum and it gave me the availability of doing everything, from sending to all types of addresses whether legacy or native SegWit or a compatible one, so your choice remains best currently, but if you are a bit more advanced, you can go for Mycelium too. And yeah, SegWit will help you save your fee a bit as the costs are evaluated through virtual bytes.

actually addresses starting with 1 (ie. P2PKH outputs) produce low tier transaction sizes so if anything they are medium size. the "most expensive" or the biggest transaction size is from P2SH outputs that correspond to multi-signature redeem scripts since they contain multiple signatures and some additional overhead.

I think the best one is segwit as it right now not all websites support native segwit wallet address starting with bc.

Its the obsolete systems that check for "valid" bitcoin addresses that refuse bech32, even when they already have a perfectly validating bitcoin node running in their platform.

I have both types, a "Legacy" (starting with 3) and a "Native" starting with bc1q. I use the native for everything, the only reason i kept a legacy address is because of one pesky mining pool too stubborn to bother with native, but the difference in fees is noticeable especially when you do like me to always use 1 sat/B transactions (rather than 400ish sats they are like 150ish).

There is no need to keep the ones starting with 1, those are the ones with most expensive transaction fees. You can just keep the bip39 wallet (starts with 3) and a native segwit (bc1q).

BTW: multi-sig addresses start with 3, don't confuse with those. Even worse, at some point in a long forgotten past, Litecoin also used them.

And don't forget to always force your tx fee, there is no point in using anything but 1 sat/B unless its "urgent". You can wait minutes, hours, you can probably wait a day for most things think about it and set the fee manually. Don't fall for that silly "guess the network traffic" (and its exploitable abuse) thing. Most of my 1 sat/B transactions get confirmed within the hour, only exception was Jan 2018, but that hasn't occurred ever again, and besides you can always accelerate later with RBF replace by fee thing.

In my view, 1 Sat/B should be the default and only rarely for extraordinary reasons should people ever touch that.

Also, the number of inputs matter a lot, some wallets let you use more or fewer for various reasons (Its easy to configure in Electrum, don't know about the others).

If you are totally new to crypto, then you should make a legacy address and it will serve your purpose. I am still using the legacy wallets ever since I made them a long time ago and didn't find any need to switch to the segwit wallet.

Note that receiving on SegWit address is only marginally cheaper than receiving on Legacy addresses. The majority of the savings made by using SegWit addresses are from when you send coins out of them.

If the services you are using refuse to accept Bech32 addresses, then create a P2SH wallet by downloading this site (https://iancoleman.io/bip39/), running it on a live OS on an offline computer, write down the seed phrase it gives you, go to Electrum, select "Standard wallet", "I already have a seed", type in the seed phrase you just wrote down, select "Options" and check "BIP39 seed", click next and then select "p2sh-segwit".

If the services you are using do accept Bech32 addresses, then just create a new wallet in Electrum the normal way and select "SegWit" rather than "Legacy".

Personally, I haven't used anything other than Bech32 addresses for probably over a year now. If a service still doesn't support Bech32 after all this time, then I would be looking for a new service to use.

Technically he's importing his existing wallet and not creating a new one. Anyway, that's not a huge problem.

you mean "senders"? the ones sending you bitcoin need to accept bech32 addresses otherwise your only option is to use nested SegWit addresses (starting with 3).
it doesn't matter what type of address the "receiver" is using, when your wallet client (Electrum in this case) supports all of them you can send from any address type to any address type (eg. from bech32 address to bech32, or from bech32 to base58).

ps. to OP you can also check https://coinb.in/#fees although it doesn't have nested SegWit input sizes.

If you are not certain about what to do I think that 3* SegWit compatible wallet is the best choice.
No matter what wallet you choose, if you send towards an old 1* wallet you'll still pay bigger fee I think. And that's because of the nr of vbytes, not because of your choice of fee/vbyte.
But the problem I see is that you didn't check how crowded the mempool is. I think that your tx wouldn't have needed more than 2 sat/vbyte.


It does.
I was wrong. You can create 3* wallet with Electrum only if you get the seed from somewhere else (IanColeman?) with "I already have a seed" and set in options it's Bip39 so you can select the derivation path.

It depends on receivers (the one you deal with or the service you use), there are lists of wallets that support Segwit address or not (for software and hardware wallets).

Software wallets	Hardware wallets
____________________________________	____________________________________

Sources:
https://en.bitcoin.it/wiki/Bech32_adoption#Software_Wallets
https://en.bitcoin.it/wiki/Bech32_adoption#Hardware_Wallets

That depends on whether whoever send you Bitcoin use wallet which support send to Bech32 address, if you're not sure choosing SegWit (address with prefix 3) is best option.

I don't remember Electrum have option to create SegWit (address with prefix 3)  though, unless you're creating 2FA, CMIIW.