is it possible to send transactions back and forth between all 3 address types (legacy, segwit, native segwit-bech32)?

Or is one of them not able to send to another?


Each address type is backwards compatable with the previous one. So a segwit address has all of the benefits of the previous versions built into it and knows how to utilize them. A legacy address doesn't know about any of the segwit code, and cannot benefit from any of the improvements.

This all get's tied together at the transaction level. Sending segwit -> segwit you get all of the benefits. Sending legacy -> segwit you don't get any, as the transaction can't support information coming from the legacy address to implement it into any segwit functions.

That being said, older clients may not recognize newer versions of addresses as valid, and won't let you send to them (as a precautionary measure to prevent users from sending to a non-bitcoin address) if you manually broadcast the transaction on the bitcoin network itself, it would send.

  • 1
    The first paragraph seems to imply that it's not possible to send from some address types to others, but funds from any address type can be sent to any other address type. I'm also confused what "a legacy address doesn't know about […] segwit code" or "the transaction can't support information coming from the legacy address to implement it into any segwit functions" are supposed to mean. It's not possible to chose which format to use to spend a UTXO. The required input script is defined by the address type the funds were previously sent to. – Murch Feb 3 at 2:54
  • I've added another answer that addresses the question more broadly than Pieter's and revisits some of the points hinted at in this answer. – Murch Feb 3 at 3:21

At a protocol level, they are all compatible. Transactions can spend any of them, and send to any of them.

Wallet software may of course have restrictions, but these are usually not about combinations. E.g. some wallets may be unable to generate a p2sh-segwit address to receive on, or be unable to send to bech32. However, I have not heard about software that puts restrictions on where it can send to based on what is being spent, for example.


There are no restrictions on sending from any type of outputs to any address type in the Bitcoin protocol, but some older wallets might not support sending to newer address types.

Let's take a better look at what happens for a Bitcoin transaction coming to pass:

  • The recipient picks an address they would like to receive funds to. This will be an address format their wallet knows how to spend funds from. It is in the recipient's interest to pick a more efficient address format to save cost on spending the funds they will be receiving later.
  • The sender picks the inputs they want to spend. The input scripts are set in stone by the address type these outputs were received to before. The sender is incentivized to pick an efficient address type for their change output to save future costs, though.
  • Older wallet software may not be able to send to newer address types. Specifically, native segwit addresses only got an address standard in March 2017 (BIP-173), and not all wallets support sending to these addresses yet. In that case, the sender should instead provide a wrapped segwit address. All wallets should be able to send to wrapped segwit addresses as that uses the Pay to Script Hash (p2sh, BIP-16) address standard which was introduced in 2012.

In any case, issues with sending to any specific address type are caused by missing functionality in the sender's wallet and in no way related to the input types used.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.