<p><strong>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.</strong></p>
<p>Let's take a better look at what happens for a Bitcoin transaction coming to pass:</p>
<ul>
<li>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.</li>
<li>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.</li>
<li>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 (<a href="https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki" rel="noreferrer">BIP-173</a>), and not all wallets support sending to these addresses yet. In that case, the sender should ask the receiver to 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, <a href="https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki" rel="noreferrer">BIP-16</a>) address standard which was introduced in 2012.</li>
</ul>
<p>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.</p>

CC BY-SA 4.0
2020-02-03T03:18:48.607Z
2020-12-18T00:51:52.297Z
2020-12-18T00:51:52.297Z
Murch
<p>At a protocol level, they are all compatible. Transactions can spend any of them, and send to any of them.</p>

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

CC BY-SA 4.0
2020-07-16T05:41:32.633Z
There're privacy-related implications that different address types can possibly reveal the true change address, therefore some wallet may provide the option to avoid this. I saw reminds about this on Mycelium wallet.
Chris Chen
CC BY-SA 4.0
2020-12-18T21:03:38.077Z
The privacy implication is not so much about change addresses specifically, but being able to determine what type of wallet client was used to send the transaction (potentially helping to narrow down the true owner). Change address privacy has to do with the difference in value between the two outputs. If a transaction sends the following values to two addresses: 0.524 and 0.489, it is more difficult to guess which is the change address vs. outputs like 0.5 and 0.00021 (the exact value is probably not change).
jon.bray.eth
CC BY-SA 4.0
2020-01-28T22:10:27.117Z
2020-01-29T01:30:31.887Z
2020-01-29T01:30:31.887Z
Pieter Wuille
<blockquote>
<p>is it possible to send transactions back and forth between all 3 address types (legacy, segwit, native segwit-bech32)?</p>
</blockquote>
<p>Yes, of course. It's totally normal at protocol level.</p>
<p>Just like what Murch had said:</p>
<blockquote>
<p>There are no restrictions on sending from any type of outputs to any address type in the Bitcoin protocol</p>
</blockquote>
<p>The ability to limit where the &quot;unlocked&quot; bitcoin (UTXO) could go is actually a missing feature of bitcoin, called &quot;covenants&quot;. Currently people could only use tricks like presigned time-locked transactions to achieve similar goals. In the future maybe this could be done in a more intuitive and powerful way.</p>
<hr />
<p>However, an old wallet (or a cryptocurrency exchange with lazy/conservative technical team) may not be able to recognise native bech32 addresses, so that you won't be able to send bitcoins from such an old wallet (or withdraw from such a lazy cryptocurrency exchange) to a native bech32 SegWit address - that's the only significant downside.</p>
<p>To summarize:</p>
<p><strong>Miner fee</strong>: (Most expensive) 1-starting legacy address &gt; 3-starting p2sh-segwit &gt; bc1-starting bech32 (cheapest)</p>
<p><strong>Compatibility</strong>: (Most compatible) 1-starting legacy address ≈ 3-starting p2sh-segwit (almostly as compatible as legacy) &gt; bc1-starting bech32 (potential compatibility/interoperability issue)</p>
<p>Also, obviously you can't generate any SegWit address with an old wallet without any SegWit support, so that you can't receive bitcoins with any SegWit address using such a wallet - the solution to this problem is simple: just upgrade the wallet to SegWit-supporting version, or switch to another wallet with proper SegWit support.</p>
<p>If someone who is too stubborn to upgrade/switch his/her wallet, it doesn't matter, because (1) you can still give him/her a 3-starting SegWit address; (2) you can totally send transactions back and forth between all 3 address types using a wallet with proper SegWit support.</p>
<hr />
<p>(A transaction sending bitcoins all from) 1-starting P2PKH legacy addresses doesn't enjoy <strong>discounts</strong> of SegWit, so that it has the most expensive miner fees among those three address types. Its virtual byte count is exactly the same with actual/on-wire byte count.</p>
<p>(A transaction sending bitcoins from) bc1-starting native Bech32 SegWit address has the least data size (byte count), either virtual (vByte) or actual/on-wire, so that it enjoys the cheapest miner fees.</p>
<p><em>In fact SegWit (v0) doesn't reduce transaction data size so much, its cheap miner fee is mainly an artificial discount. However SegWit transactions indeedly has technical advantage over legacy ones, like, avoiding <a href="https://bitcoincore.org/en/2016/01/26/segwit-benefits/#linear-scaling-of-sighash-operations" rel="nofollow noreferrer">the quadratic sighash problem</a>.</em></p>
<p>(A transaction sending bitcoins from) 3-starting P2SH-wrapped &quot;compatible&quot; SegWit address actually consumes more bytes than a legacy 1-starting address (mainly because P2SH &quot;script hash&quot; itself consumes 20 bytes), however, it still has cheaper miner fee than 1-starting legacy address due to discounts.</p>
<hr />
<p>A 3-starting address is <a href="https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki" rel="nofollow noreferrer">P2SH</a>, which was brought by Gavin Andresen at very early stage of the history of bitcoin (2012), so that it's now highly improbable to see a wallet which can't recognise 3-starting P2SH addresses.</p>
<p>SegWit utilize P2SH to &quot;wrap&quot; its special &quot;anyone-can-spend&quot; <a href="https://en.bitcoin.it/wiki/Script" rel="nofollow noreferrer">script</a>.</p>
<p>P2SH can actually &quot;wrap&quot; anything. Its typical usage has been multi-sig for quite a long time, much earlier than SegWit.</p>
<p>When an old wallet sends bitcoins to a 3-starting address, it (the payer) doesn't care about what kind of stuff is &quot;wrapped inside&quot; that address at all. It can be either a legacy multi-sig, SegWit, or something other - whatever, it doesn't matter.</p>
<p><em>(It could even be a totally unspendable address!)</em></p>
<p>It's then the responsibility of the payee to ensure that (s)he can still spend the bitcoins on that 3-starting address.</p>
<hr />
<p>Then what's &quot;anyone-can-spend&quot;?</p>
<p>Old versions (pre-0.13) of bitcoin full nodes don't know about SegWit at all of course, so that they obviously cannot validate SegWit transactions (or blocks containing SegWit transactions) according to the newly defined SegWit rules.</p>
<p>However they would still accept SegWit blocks as if those <strong>blocks</strong> were valid, despite they cannot fully validate them - the forward compatibility (usually called &quot;backwards compatibility&quot; by a lot of developers) is still retained, in the sense that old nodes which are not SegWit-aware can still work as normal.</p>
<p>As for SegWit <strong>transactions</strong>, those old nodes won't accept/forward/mine any SegWit transactions (except sending to a 3-starting P2SH-wrapped SegWit address). They would accept <strong>confirmed</strong> SegWit transactions only, in other words, SegWit blocks only. Therefore, if you want to break SegWit rules, you must at least become a (solo) miner yourself, an almostly cost-free attempt like sending invalid &quot;robbing&quot; transaction from some SegWit addresses won't work at all. <em>(Here comes the minor downside of SegWit that old non-SegWit-aware full nodes can't see 0-confirmation SegWit transactions)</em></p>
<p>SegWit was carefully designed to achieve this. It's actually quite similar to what P2SH had done.</p>
<p>There's a concept called &quot;standardness rules&quot; in bitcoin, that such rules are just self-discipline, so that they only restrict the behavoir of a full node <strong>itself</strong>. &quot;Standardness rules&quot; don't apply to the blockchain, which contains blocks mined by various types of other nodes.</p>
<p>Only &quot;validity rules&quot; or &quot;consensus rules&quot; apply to the blockchain.</p>
<p>SegWit address actually means &quot;anyone can spend bitcoins on this address&quot; according to <em>old validity rules</em>, so that old nodes would still accept SegWit blocks. (Therefore, there's indeedly a theoretical, unavoidable risk that a chain split could happen, if some malicious miners would insist on mining/extending an invalid blockchain &quot;robbing&quot; SegWit addresses - however it would be still clearly distinguishable between the valid chain and the invalid chain. SegWit-aware new nodes would only accept the valid chain) It violates the <em>old standardness rules</em>, so that old nodes won't mine any SegWit transactions into their own blocks.</p>
<p>According to <em>new validity rules</em>, spending bitcoins from SegWit address (typically) must provide valid signatures, without all-valid signatures it would be an invalid transaction, so that new nodes would reject either such an invalid transaction, or a (thus invalid) block including any invalid transaction. New nodes won't mine any invalid transaction into their own blocks either, of course. However, according to the <em>new standardness rules</em>, (valid) SegWit transactions is also <em>standard</em> (not violating the new standardness rules), so that new nodes would happily mine valid SegWit transactions into their own blocks.</p>

CC BY-SA 4.0
2020-07-15T16:46:53.210Z
2020-07-16T05:34:35.993Z
2020-07-16T05:34:35.993Z
Chris Chen
<h3>Absolutely!</h3>
<p>Each address type handles transaction generation slightly differently but they all are interoperable with each other on the protocol level. If you run into an issue where one address type will not send to another, this is <strong>not</strong> a limitation of the bitcoin code, rather the client.</p>
<p>Still, you may hear something like:</p>
<blockquote>
<p>&quot;Legacy addresses are not SegWit compatible&quot;</p>
</blockquote>
<p>This simply means a legacy address cannot <strong>send</strong> a SegWit
transaction. When it comes to <strong>receiving</strong>, everything is interoperable. <em>The type of transaction and whether or not the receiving address can fully utilize all transaction benefits depends on the sending address.</em></p>
<h2>Legacy Address</h2>
<p>Bitcoin's original address format—Pay-to-Pubkey Hash (P2PKH)—builds a transaction using a hash of the recipient's public key. If an address starts with <code>1</code>, it's legacy. It is still in common use due to the simplicity and universal integration, and while P2PKH can send to a SegWit address, the fee is a little higher because legacy transactions are slightly larger.</p>
<h2>P2SH Address</h2>
<p>These addresses begin with a <code>3</code> and are designed to <strong>pay to script hash</strong> adding basic scripting functionality to addresses. The transaction has extra logic that—in the case of multi-sig—states that multiple signatures are required to authorize the transaction. As long as all required signatures are in place, any address can receive a transaction from this address.</p>
<blockquote>
<p>If you've heard the term &quot;non-native SegWit&quot;, or wondered why SegWit is called &quot;native SegWit&quot; that is because of this address. Even though the <strong>sending address</strong> is not SegWit, a P2SH transaction is created which contains a &quot;Pay-to-Witness-Pubkey Hash&quot; inside of it. This mimics SegWit formatting, allowing a native SegWit address to interpret it, well... natively.</p>
</blockquote>
<h2>SegWit &amp; Bech32</h2>
<p>Bech32 is the native SegWit address format and is more efficient with block space. A Bech32 address can be identified by it's <code>bc1</code> prefix. SegWit is a transaction format that splits (<strong>Seg</strong>regates) a transaction into two pieces: one containing the standard transaction ID data (to, from, amount, signatures, etc.), and a scripted piece of that data (<strong>Wit</strong>ness) that is 75% smaller on-chain <a href="https://bitcoincore.org/en/2016/01/26/segwit-benefits/" rel="nofollow noreferrer">among other benefits</a>. Since the witness contains, among other things, a &quot;minified version&quot; of legacy data it allows a SegWit transaction to be sent to a legacy address (without cost benefit), or to a SegWit address (as a cheaper transaction relying on the witness only).
A legacy address however doesn't know how to generate the witness data, so it cannot include it in a SegWit transaction and reap the benefits. That's okay though, because a SegWit address doesn't <strong>need</strong> the witness data, so a legacy address will have no problem sending tokens to a SegWit address.</p>
<h2>Fully Benefiting from SegWit</h2>
<p>No matter what wallet you use, any UTXO may have come from any address type. For any coin in an address, the UTXO it arrived in either contains the legacy data, the witness data, or both, depending on what type of transaction was used to send the coins.</p>
<p>If you're using a Bech32 address to send a SegWit transaction, its full benefits are realized when a UTXO was sent to you as a SegWit transaction, but will always send regardless.</p>
<h2>Mixed Script Transactions</h2>
<p>These are transactions where UTXOs that may have come from different address types are placed into a single transaction. It's also an illustration of what happens when coins are sent to different address types through their lifecycle. Example:</p>
<ol>
<li>Alice receives 0.5 BTC to her SegWit wallet from Bob's legacy address.</li>
<li>Alice receives 0.5 BTC from Charlie that were sent using SegWit.</li>
<li>Alice sends a 1 BTC transaction which uses both legacy and native SegWit transactions to a Bech32 address.</li>
</ol>
<p>The result is a SegWit transaction, although it does not fully benefit from the privacy or transaction cost reduction had all UTXOs been SegWit. If it was sent to a legacy address, any further movement of the coins will be legacy transactions, until it reaches a Bech32 address which sends it as a SegWit transaction, at which point it becomes again a SegWit transaction.</p>
<blockquote>
<p>NOTE: Some older wallet clients, or ones without SegWit support may not recognize newer versions of addresses as valid, and won't let you send to them: this is a precautionary measure (in the wallet code, not bitcoin code) to prevent users from sending to a non-bitcoin address.</p>
</blockquote>
<h2>Taproot - <code>Update (Nov 2021)</code></h2>
<p>The recent Taproot upgrade added additional transaction changes by enabling Schnorr signing in addition to the traditional Elliptic Curve Digital Signature Algorithm (ECDSA). When bitcoin was originally released, the Schnorr algorithm was under patent protection. <a href="https://river.com/learn/what-are-schnorr-signatures/#the-advantages-of-schnorr-signatures" rel="nofollow noreferrer">There are many benefits that come with using Schnorr</a>, most importantly the ability to aggregate signing keys. While a P2SH multi-sig includes each parties public key and signature, Schnorr enables the keys to be aggregated, providing privacy and easier computation for nodes.</p>
<p>Since the aggregate key is still used to create a signed UTXO with the necessary inputs and outputs, even a new algorithm is compatible with all existing bitcoin clients!</p>

CC BY-SA 4.0
2020-02-03T02:54:21.070Z
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
CC BY-SA 4.0
2020-02-03T03:21:10.250Z
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
CC BY-SA 4.0
2020-12-17T06:58:33.387Z
Updated to clarify, thank you for pointing this out. I mean that older transaction types cannot benefit from later protocols, as they are unaware of the new code. While it's not possible to chose which format you use to spend a UTXO, it is possible to send a transaction with mixed scripts.
jon.bray.eth
CC BY-SA 4.0
2020-12-18T00:48:43.227Z
Thank you for addressing the comment about being able to send between address formats. I would still recommend that the phrasing of "addresses knowing things" would be updated. The segwit-awareness is a feature of wallet software, not of an address. Likewise, "[…] will take advantage of the transaction fee updates" is a bit circuitous—the input script for segwit UTXOs simply has less weight, thus it costs less fees to spent such UTXOs in a transaction.
Murch
CC BY-SA 4.0
2020-12-18T20:48:16.227Z
@Murch Good point on phrasing of "transaction fee updates"—I meant "benefits" (SE forum check is usually an end-of-day activity for me). I've updated to make the example more concise. Feel free to suggest edits to the answer; since it is the accepted answer and many users stop there, I want to make sure it is as correct and helpful as possible!
jon.bray.eth
CC BY-SA 4.0
2021-11-30T15:50:22.560Z
I don't get it. You correctly explain that compatibility is a __wallet__ property in the first paragraph, but then you write "X addresses cannot send to Y addresses" and "addresses build transactions", which makes no sense. Addresses don't do anything. **Wallets** build transactions, and wallets can send to any address formats they support, regardless of the type of outputs they spend.
Murch
CC BY-SA 4.0
2021-11-30T15:54:51.237Z
E.g. for "This simply means a legacy address cannot send a SegWit transaction.", did you mean "This simply means that a legacy output cannot be spent as a segwit input." Or perhaps "This simply means that some wallet using legacy addresses cannot create segwit outputs."?
Murch
CC BY-SA 4.0
2020-01-29T02:55:47.570Z
2021-11-30T01:26:59.360Z
2021-11-30T01:26:59.360Z
jon.bray.eth
<p>is it possible to send transactions back and forth between all 3 address types (legacy, segwit, native segwit-bech32)?</p>

<p>Or is one of them not able to send to another?</p>

<transactions><wallet><segregated-witness><bech32-address>
Are all three Bitcoin address types interoperable (legacy, segwit, native segwit)?
johnsmiththelird
# Are all three Bitcoin address types interoperable (legacy, segwit, native segwit)?

(Asked by: username_0 on 2020-01-28)

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?

**Tags:** transactions, wallet, segregated-witness, bech32-address


---

## 4 answers

### Answer by username_4 on 2020-01-29. Score: 14 | Accepted answer

### Absolutely!

Each address type handles transaction generation slightly differently but they all are interoperable with each other on the protocol level. If you run into an issue where one address type will not send to another, this is **not** a limitation of the bitcoin code, rather the client.

Still, you may hear something like:

> "Legacy addresses are not SegWit compatible"

This simply means a legacy address cannot **send** a SegWit
transaction. When it comes to **receiving**, everything is interoperable. *The type of transaction and whether or not the receiving address can fully utilize all transaction benefits depends on the sending address.*

## Legacy Address

Bitcoin's original address format—Pay-to-Pubkey Hash (P2PKH)—builds a transaction using a hash of the recipient's public key. If an address starts with `1`, it's legacy. It is still in common use due to the simplicity and universal integration, and while P2PKH can send to a SegWit address, the fee is a little higher because legacy transactions are slightly larger.

## P2SH Address

These addresses begin with a `3` and are designed to **pay to script hash** adding basic scripting functionality to addresses. The transaction has extra logic that—in the case of multi-sig—states that multiple signatures are required to authorize the transaction. As long as all required signatures are in place, any address can receive a transaction from this address.

> If you've heard the term "non-native SegWit", or wondered why SegWit is called "native SegWit" that is because of this address. Even though the **sending address** is not SegWit, a P2SH transaction is created which contains a "Pay-to-Witness-Pubkey Hash" inside of it. This mimics SegWit formatting, allowing a native SegWit address to interpret it, well... natively.

## SegWit & Bech32

Bech32 is the native SegWit address format and is more efficient with block space. A Bech32 address can be identified by it's `bc1` prefix. SegWit is a transaction format that splits (**Seg**regates) a transaction into two pieces: one containing the standard transaction ID data (to, from, amount, signatures, etc.), and a scripted piece of that data (**Wit**ness) that is 75% smaller on-chain [among other benefits](https://bitcoincore.org/en/2016/01/26/segwit-benefits/). Since the witness contains, among other things, a "minified version" of legacy data it allows a SegWit transaction to be sent to a legacy address (without cost benefit), or to a SegWit address (as a cheaper transaction relying on the witness only).
A legacy address however doesn't know how to generate the witness data, so it cannot include it in a SegWit transaction and reap the benefits. That's okay though, because a SegWit address doesn't **need** the witness data, so a legacy address will have no problem sending tokens to a SegWit address.

## Fully Benefiting from SegWit

No matter what wallet you use, any UTXO may have come from any address type. For any coin in an address, the UTXO it arrived in either contains the legacy data, the witness data, or both, depending on what type of transaction was used to send the coins.

If you're using a Bech32 address to send a SegWit transaction, its full benefits are realized when a UTXO was sent to you as a SegWit transaction, but will always send regardless.

## Mixed Script Transactions

These are transactions where UTXOs that may have come from different address types are placed into a single transaction. It's also an illustration of what happens when coins are sent to different address types through their lifecycle. Example:

1. Alice receives 0.5 BTC to her SegWit wallet from Bob's legacy address.
2. Alice receives 0.5 BTC from Charlie that were sent using SegWit.
3. Alice sends a 1 BTC transaction which uses both legacy and native SegWit transactions to a Bech32 address.

The result is a SegWit transaction, although it does not fully benefit from the privacy or transaction cost reduction had all UTXOs been SegWit. If it was sent to a legacy address, any further movement of the coins will be legacy transactions, until it reaches a Bech32 address which sends it as a SegWit transaction, at which point it becomes again a SegWit transaction.

> NOTE: Some older wallet clients, or ones without SegWit support may not recognize newer versions of addresses as valid, and won't let you send to them: this is a precautionary measure (in the wallet code, not bitcoin code) to prevent users from sending to a non-bitcoin address.

## Taproot - `Update (Nov 2021)`

The recent Taproot upgrade added additional transaction changes by enabling Schnorr signing in addition to the traditional Elliptic Curve Digital Signature Algorithm (ECDSA). When bitcoin was originally released, the Schnorr algorithm was under patent protection. [There are many benefits that come with using Schnorr](https://river.com/learn/what-are-schnorr-signatures/#the-advantages-of-schnorr-signatures), most importantly the ability to aggregate signing keys. While a P2SH multi-sig includes each parties public key and signature, Schnorr enables the keys to be aggregated, providing privacy and easier computation for nodes.

Since the aggregate key is still used to create a signed UTXO with the necessary inputs and outputs, even a new algorithm is compatible with all existing bitcoin clients!

> **Comments:**
> **username_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.  
> **username_1**: I've added another answer that addresses the question more broadly than username_2's and revisits some of the points hinted at in this answer.  
> **username_4**: Updated to clarify, thank you for pointing this out. I mean that older transaction types cannot benefit from later protocols, as they are unaware of the new code. While it's not possible to chose which format you use to spend a UTXO, it is possible to send a transaction with mixed scripts.  
> **username_1**: Thank you for addressing the comment about being able to send between address formats. I would still recommend that the phrasing of "addresses knowing things" would be updated. The segwit-awareness is a feature of wallet software, not of an address. Likewise, "[…] will take advantage of the transaction fee updates" is a bit circuitous—the input script for segwit UTXOs simply has less weight, thus it costs less fees to spent such UTXOs in a transaction.  
> **username_4**: @username_1 Good point on phrasing of "transaction fee updates"—I meant "benefits" (SE forum check is usually an end-of-day activity for me). I've updated to make the example more concise. Feel free to suggest edits to the answer; since it is the accepted answer and many users stop there, I want to make sure it is as correct and helpful as possible!  
> **username_1**: I don't get it. You correctly explain that compatibility is a __wallet__ property in the first paragraph, but then you write "X addresses cannot send to Y addresses" and "addresses build transactions", which makes no sense. Addresses don't do anything. **Wallets** build transactions, and wallets can send to any address formats they support, regardless of the type of outputs they spend.  
> **username_1**: E.g. for "This simply means a legacy address cannot send a SegWit transaction.", did you mean "This simply means that a legacy output cannot be spent as a segwit input." Or perhaps "This simply means that some wallet using legacy addresses cannot create segwit outputs."?  

---

### Answer by username_1 on 2020-02-03. Score: 9

**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](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki)), and not all wallets support sending to these addresses yet. In that case, the sender should ask the receiver to 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](https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki)) 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.


---

### Answer by username_2 on 2020-01-28. Score: 7

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.

> **Comments:**
> **username_3**: There're privacy-related implications that different address types can possibly reveal the true change address, therefore some wallet may provide the option to avoid this. I saw reminds about this on Mycelium wallet.  
> **username_4**: The privacy implication is not so much about change addresses specifically, but being able to determine what type of wallet client was used to send the transaction (potentially helping to narrow down the true owner). Change address privacy has to do with the difference in value between the two outputs. If a transaction sends the following values to two addresses: 0.524 and 0.489, it is more difficult to guess which is the change address vs. outputs like 0.5 and 0.00021 (the exact value is probably not change).  

---

### Answer by username_3 on 2020-07-15. Score: 3

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

Yes, of course. It's totally normal at protocol level.

Just like what username_1 had said:

> There are no restrictions on sending from any type of outputs to any address type in the Bitcoin protocol

The ability to limit where the "unlocked" bitcoin (UTXO) could go is actually a missing feature of bitcoin, called "covenants". Currently people could only use tricks like presigned time-locked transactions to achieve similar goals. In the future maybe this could be done in a more intuitive and powerful way.

---

However, an old wallet (or a cryptocurrency exchange with lazy/conservative technical team) may not be able to recognise native bech32 addresses, so that you won't be able to send bitcoins from such an old wallet (or withdraw from such a lazy cryptocurrency exchange) to a native bech32 SegWit address - that's the only significant downside.

To summarize:

**Miner fee**: (Most expensive) 1-starting legacy address > 3-starting p2sh-segwit > bc1-starting bech32 (cheapest)

**Compatibility**: (Most compatible) 1-starting legacy address ≈ 3-starting p2sh-segwit (almostly as compatible as legacy) > bc1-starting bech32 (potential compatibility/interoperability issue)

Also, obviously you can't generate any SegWit address with an old wallet without any SegWit support, so that you can't receive bitcoins with any SegWit address using such a wallet - the solution to this problem is simple: just upgrade the wallet to SegWit-supporting version, or switch to another wallet with proper SegWit support.

If someone who is too stubborn to upgrade/switch his/her wallet, it doesn't matter, because (1) you can still give him/her a 3-starting SegWit address; (2) you can totally send transactions back and forth between all 3 address types using a wallet with proper SegWit support.

---

(A transaction sending bitcoins all from) 1-starting P2PKH legacy addresses doesn't enjoy **discounts** of SegWit, so that it has the most expensive miner fees among those three address types. Its virtual byte count is exactly the same with actual/on-wire byte count.

(A transaction sending bitcoins from) bc1-starting native Bech32 SegWit address has the least data size (byte count), either virtual (vByte) or actual/on-wire, so that it enjoys the cheapest miner fees.

*In fact SegWit (v0) doesn't reduce transaction data size so much, its cheap miner fee is mainly an artificial discount. However SegWit transactions indeedly has technical advantage over legacy ones, like, avoiding [the quadratic sighash problem](https://bitcoincore.org/en/2016/01/26/segwit-benefits/#linear-scaling-of-sighash-operations).*

(A transaction sending bitcoins from) 3-starting P2SH-wrapped "compatible" SegWit address actually consumes more bytes than a legacy 1-starting address (mainly because P2SH "script hash" itself consumes 20 bytes), however, it still has cheaper miner fee than 1-starting legacy address due to discounts.

---

A 3-starting address is [P2SH](https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki), which was brought by Gavin Andresen at very early stage of the history of bitcoin (2012), so that it's now highly improbable to see a wallet which can't recognise 3-starting P2SH addresses.

SegWit utilize P2SH to "wrap" its special "anyone-can-spend" [script](https://en.bitcoin.it/wiki/Script).

P2SH can actually "wrap" anything. Its typical usage has been multi-sig for quite a long time, much earlier than SegWit.

When an old wallet sends bitcoins to a 3-starting address, it (the payer) doesn't care about what kind of stuff is "wrapped inside" that address at all. It can be either a legacy multi-sig, SegWit, or something other - whatever, it doesn't matter.

*(It could even be a totally unspendable address!)*

It's then the responsibility of the payee to ensure that (s)he can still spend the bitcoins on that 3-starting address.

---

Then what's "anyone-can-spend"?

Old versions (pre-0.13) of bitcoin full nodes don't know about SegWit at all of course, so that they obviously cannot validate SegWit transactions (or blocks containing SegWit transactions) according to the newly defined SegWit rules.

However they would still accept SegWit blocks as if those **blocks** were valid, despite they cannot fully validate them - the forward compatibility (usually called "backwards compatibility" by a lot of developers) is still retained, in the sense that old nodes which are not SegWit-aware can still work as normal.

As for SegWit **transactions**, those old nodes won't accept/forward/mine any SegWit transactions (except sending to a 3-starting P2SH-wrapped SegWit address). They would accept **confirmed** SegWit transactions only, in other words, SegWit blocks only. Therefore, if you want to break SegWit rules, you must at least become a (solo) miner yourself, an almostly cost-free attempt like sending invalid "robbing" transaction from some SegWit addresses won't work at all. *(Here comes the minor downside of SegWit that old non-SegWit-aware full nodes can't see 0-confirmation SegWit transactions)*

SegWit was carefully designed to achieve this. It's actually quite similar to what P2SH had done.

There's a concept called "standardness rules" in bitcoin, that such rules are just self-discipline, so that they only restrict the behavoir of a full node **itself**. "Standardness rules" don't apply to the blockchain, which contains blocks mined by various types of other nodes.

Only "validity rules" or "consensus rules" apply to the blockchain.

SegWit address actually means "anyone can spend bitcoins on this address" according to *old validity rules*, so that old nodes would still accept SegWit blocks. (Therefore, there's indeedly a theoretical, unavoidable risk that a chain split could happen, if some malicious miners would insist on mining/extending an invalid blockchain "robbing" SegWit addresses - however it would be still clearly distinguishable between the valid chain and the invalid chain. SegWit-aware new nodes would only accept the valid chain) It violates the *old standardness rules*, so that old nodes won't mine any SegWit transactions into their own blocks.

According to *new validity rules*, spending bitcoins from SegWit address (typically) must provide valid signatures, without all-valid signatures it would be an invalid transaction, so that new nodes would reject either such an invalid transaction, or a (thus invalid) block including any invalid transaction. New nodes won't mine any invalid transaction into their own blocks either, of course. However, according to the *new standardness rules*, (valid) SegWit transactions is also *standard* (not violating the new standardness rules), so that new nodes would happily mine valid SegWit transactions into their own blocks.


---

