[SOLVED] Sending Bitcoin from legacy address to segwit address?

[tyz]

I wonder if it is possible to send Bitcoins from a legacy address (1 ...) to a Segwit address (b2 ...) and vice versa?
The reason is, I have Bitcoins on a Segwit address and the recipient service only provides a legacy address for deposit.

[1715350419]

1715350419

[Rath_]

I wonder if it is possible to send Bitcoins from a legacy address (1 ...) to a Segwit address (b2 ...) and vice versa?

Yes, it is. You can send to a native SegWit address (bc1...) as long as your wallet supports sending to such addresses (which most popular wallets do). Any service can receive from native SegWit addresses.

[Daniel91]

I wonder if it is possible to send Bitcoins from a legacy address (1 ...) to a Segwit address (b2 ...) and vice versa?

Yes, it is. You can send to a native SegWit address (bc1...) as long as your wallet supports sending to such addresses (which most popular wallets do). Any service can receive from native SegWit addresses.

I can confirm it.
I already sent bitcoin funds from a legacy address to a segwit and vice versa many times. No problem here.

[tyz]

I wonder if it is possible to send Bitcoins from a legacy address (1 ...) to a Segwit address (b2 ...) and vice versa?

Yes, it is. You can send to a native SegWit address (bc1...) as long as your wallet supports sending to such addresses (which most popular wallets do). What wallet do you use? You might be able to generate a nested SegWit address (3...) which will be compatible with all services and will let you save a little on the fees.

Thanks for your fast answer! I am currently using Electrum where I have two different wallets: one to manage my Legacy addresses and one to manage my SegWit addresses. I've never heard about nested SegWit addresses. Do you know if Electrum supports nested segwit addresses?

[Rath_]

Thanks for your fast answer! I am currently using Electrum where I have two different wallets: one to manage my Legacy addresses and one to manage my SegWit addresses. I've never heard about nested SegWit addresses. Do you know if Electrum supports nested segwit addresses?

Oh, I actually removed that part of my message because I thought it was irrelevant after giving it a second thought. By default, Electrum will let you generate legacy (1...) and native SegWit (bc1...) addresses. You can either use a third-party software to generate a BIP39 seed (although, you should be really careful and it is not recommended) and select p2sh-segwit during wallet recovery or you can use this trick. You can even use your current Electrum seed for this trick.

[Pffrt]

I've never heard about nested SegWit addresses.

Nested segwit address = addresses which start with "3"
When you generate seed key and want to verify, check the option and put mark on bip39 to generate nested segwit addresses.

[ShowOff]

I think the OP has got the right answer so far and that can be confirmed. But what about the transaction fees, will the transaction from the Legacy address to the Segwit address or vice versa will require a higher fee or not ?

[khaled0111]

SegWit is backwards compatible. You can send from a SegWit address to a Legacy address and the other way around without any problems.

However, some service providers (exchanges, onlie wallets...) did not upgrade their platforms to support SegWit. Therefore, you will not be able to withdraw from them to bc1 addresses but you can make deposits.

[OcTradism]

SegWit is backwards compatible. You can send from a SegWit address to a Legacy address and the other way around without any problems.

However, some service providers (exchanges, onlie wallets...) did not upgrade their platforms to support SegWit. Therefore, you will not be able to withdraw from them to bc1 addresses but you can make deposits.

You can check Bench32 adoption there. It does probably not cover all exchanges, wallets, processors, etc. but you can have a quick overview by looking at that page.

For your interested one, you can dig more on their FAQs for more details.

[Upgrade00]

But what about the transaction fees, will the transaction from the Legacy address to the Segwit address or vice versa will require a higher fee or not ?

If a segwit address is involved in a transaction (as a receiving or spending address) it will reduce the fee paid on such transaction, due to the lower virtual size.
Transaction from a segwit to a segwit address would be cheaper than a legacy to a legacy address. A sewit address to a legacy address and vice versa would also be cheaper than a legacy to a legacy address, as inputs and outputs both go into the calculation of transaction fees.

You can check out this reply as it discusses about this topic.

[bob123]

You can always send to any address type and receive from any address type.

The reason, you sometimes can not withdraw etc. is because their software has not been updated (in 3 years).
Stop using services which do not allow to withdraw to a bech32 address. They obviously do not care being up-to-date. I wouldn't trust them.

Again, the network allows you to send/receive to/from any address type.

[Rath_]

But what about the transaction fees, will the transaction from the Legacy address to the Segwit address or vice versa will require a higher fee or not ?

Legacy inputs and outputs weight more than SegWit ones (Reference).

Legacy input: 148 vbytes; Legacy output: 34 vbytes
Nested SegWit input: 93 vbytes; Nested SegWit output: 32 vbytes
Native SegWit input: 68 vbytes; Native SegWit output: 31 vbytes

These savings are mostly significant only for the senders due to drastically lower input size. Don't forget that you not only save on the fees, but also more transactions can fit in a single block.

[Asuspawer09]

I wonder if it is possible to send Bitcoins from a legacy address (1 ...) to a Segwit address (b2 ...) and vice versa?
The reason is, I have Bitcoins on a Segwit address and the recipient service only provides a legacy address for deposit.

It will work in my experience even vice versa I'm using electrum.

You could get some tips according to the wallet that you are using here in the forum so that you could have a more deep discussion.

https://bitcointalk.org/index.php?board=37.0

[bob123]

This is a matter of both your client (wallet) and you. If client is capable to do that then nothing would deter it from signing and sending  (1...) => (b2..) transaction.

Segwit address do start with bc1, not b2.

As for you yourself  it is necessary 1) to ensure the   recipient is not against such trx

There is not a single reason to be "against such a tx". This doesn't make sense.
The recipient doesn't care about the type of transaction. All he cares about is that he receives his funds.

2) to evaluate whether this is advantageous in terms of fee.

It is. Always.

[pooya87]

some sort of thing could go wrong, for example the last known issue with SegWit  https://decrypt.co/31463/bitcoin-segwit-bug-fix-could-lock-wallet-users-out-funds)

don't confuse "implementation" bugs with "protocol" bugs which the article fails to clarify too.
this has absolutely nothing to do with SegWit or even the way we sign transactions that spend SegWit outputs. it is all about the bug that the "implementation" used by hardware wallets such as Trezor have and also in how they use BIP174.

[Rath_]

Really? Even if recipient doesn't want to get fund to SegWit address simply because he has no access to it due to  the bug? I think you didn't get the point of what happened recently:

That is a false statement. Read the quote again carefully. Users won't be able to use these specific wallets until they implement the fix provided by Trezor (pull request for Electrum, for example). However, users will still be able to access their funds via the native app (Trezor Suite for native SegWit and Trezor Wallet for nested SegWit). You can also downgrade the firmware of your Trezor device.

As for you yourself  it is necessary 1) to ensure the   recipient is not against such trx

If the recipient doesn't want to have their SegWit address funded then they simply should provide a different address. I don't get your point.

[pooya87]

The key word - until.....but what if someone is in the urgent need .... "time is money" - you are probably aware of that.

those "special" cases should already have their seed phrase which can be imported in any wallet that supports them such as Electrum and then they can safely spend their money without any issues since as i said above the bug is in hardware wallet not in SegWit.

[bob123]

Really? Even if recipient doesn't want to get fund to SegWit address simply because he has no access to it due to  the bug?

If he doesn't want to receive funds to a segwit address, he should not provide one.
If you get an address, you pay to it. Doesn't matter what kind of address it is.

The recipient already chose whether he wants or doesn't want to receive funds to a segwit address by giving it to you and declaring it as the payment address.

Someone may have recipients address given him some time ago and he/she thinks it is still valuable for recipient but it's not. I always check whether the address is still topical and encourage you to do the same.

Reusing addresses is bad practice.
Whenever you pay for something you should get a new address.

[ShowOff]

Legacy inputs and outputs weight more than SegWit ones (Reference).

Legacy input: 148 vbytes; Legacy output: 34 vbytes
Nested SegWit input: 93 vbytes; Nested SegWit output: 32 vbytes
Native SegWit input: 68 vbytes; Native SegWit output: 31 vbytes

A very perfect explanation, I understand. Thank you for explaining it.

Don't forget that you not only save on the fees, but also more transactions can fit in a single block.

Thats good because the input size is lower when compared to Legacy. But because I use a mobile wallet, almost all transactions that I make must follow the suggested fees from the wallet. Not infrequently when a transaction is stuck, the recommendation fee becomes higher.

The problem now is, when mempool full, most people want higher fees so that their transactions are processed quickly. So because miners prioritize higher-fees transactions, low-fees transactions take longer to process and often take hours until they finish processing transactions at higher fees.

Is there a solution about this, or do I and others have to always face the same problem every mempool full ?

[Rath_]

The problem now is, when mempool full, most people want higher fees so that their transactions are processed quickly. So because miners prioritize higher-fees transactions, low-fees transactions take longer to process and often take hours until they finish processing transactions at higher fees.

The problem is in the software. A lot of clients suggest overpaying a lot for transactions. I personally adjust the transaction fees manually based on the current mempool state (hover your mouse over the third graph).

Is there a solution about this, or do I and others have to always face the same problem every mempool full ?

Increasing the blocksize to fix that is out of question. That is where the second layer scaling solutions (e.g. The Lightning Network) come into play. You can read the basics of it here. I have also made an FAQ thread, but please note that it is slightly out-of-date. I have almost finished reviewing it, so I should update it in the next few days.