<p>As Anonymous says, you simply cannot.</p>

<p>I'll try to highlight the important part of MCCCS's answer:</p>

<ul>
<li><p>In Bitcoin Cash, cashaddr ("bitcoincash:...", similar to, but not quite bech32) and legacy addresses ("1..." and "3...", base58) are two different ways of representing <strong>the same onchain output</strong> in a human-readable way. One can be converted into the other because the resulting transaction will be identical, and the recipient can't tell which address you used.</p></li>
<li><p>In Bitcoin, native segwit addresses ("bc1...", bech32) and legacy addresses ("1..." and "3...", base58) are addresses for <strong>distinct on-chain outputs</strong>. The first are used for BIP141 segwit outputs, while the second are not. The fact that one can be technically converted into the other is irrelevant. If the recipient gave you a native segwit address, it means he expects a transaction that pays to such an output, and he might not recognize a transaction that does anything else. In certain cases, he may be literally unable to access coins sent elsewhere (e.g. because he uses an HSM that can only sign certain transactions).</p></li>
</ul>

<p>Short answer: if you're given a native segwit address, and are unable to send to that, there is only one course of action: ask the recipient for legacy address instead.</p>

CC BY-SA 4.0
2019-12-11T19:42:04.947Z
2019-12-11T19:52:45.673Z
2019-12-11T19:52:45.673Z
Pieter Wuille
<p><em>This answer is about the differences between address formats and what causes incompatibilities.</em> <strong>If you don't code your wallet, don't trust your wallet about recognizing different addresses made from the same public key! Don't experiment with anything I've said with real money!</strong></p>

<p>In Bitcoin Cash, CashAddr and 1 addresses are different ways to encode the public key hash for Pay-2-Public-Key-Hash. To spend P2PKH outputs, the public key is revealed, for which a signature is signed. <strong>How the public key hash is serialized doesn't change how the output is spent or created</strong>. Thus those addresses are convertible.</p>

<p>Here are the information Bech32 (P2WPKH), SegWit in P2SH (P2SH-P2WPKH) and 1 addresses keep:</p>

<ul>
<li>P2PKH contains the <code>&lt;20-byte-key-hash&gt;</code></li>
<li>P2WPKH contains the <code>&lt;20-byte-key-hash&gt;</code></li>
<li>P2SH-P2WPKH contains the hash of the script <code>0 &lt;20-byte-key-hash&gt;</code></li>
</ul>

<p>Does that mean P2PKH and P2WPKH are the same? No, sending money to  the P2PKH and the Bech32 of the same public key will yield different transactions. And how the payee's wallet will spend it with the corresponding private key will be different too. But it's the same private key, the wallet should be able to spend both! When a wallet generated a <strong>Bech32 address</strong> for example, there's nothing that requires the wallet to scan for the transactions spending to that public key as <strong>P2PKH</strong> or <strong>P2SH-P2WPKH</strong>. This will depend on the implementation. (BTW, in P2PKH a compressed or uncompressed public key can be used. P2WPKH or P2SH-P2WPKH can't be used with an uncompressed public key)</p>

<p>For P2WPKH and P2SH-P2WPKH, similar to the previous case, from P2WPKH you can craft a P2SH-P2WPKH, and use it if the payee's wallet is compatible (I don't know about Bitcoin Core but there's no reason a lightweight wallet to be compatible with this). On the other hand, if you see one's P2SH-P2WPKH, you can't derive the P2WPKH or P2PKH unless that address has spent. This is related to hashing once, appending a zero, hashing again. When spent, the public key (and it's hash) are exposed.</p>

<p>Summary: It's theoretically possible but no implementation will be compatible.</p>

CC BY-SA 4.0
2019-12-11T16:26:45.790Z
This is poor advice to even suggest that wallets are able to spend funds to addresses they didn’t generate. People have done this and lost money.
Claris
CC BY-SA 4.0
2019-12-11T16:33:27.470Z
I agree, experienced developers whom I thought my answer could be helpful do not need my answer and users can be misdirected. I'll add warnings.
MCCCS
CC BY-SA 4.0
2022-01-27T04:13:17.363Z
Have you tried this on the testnet?
JustKevin
CC BY-SA 4.0
2022-06-02T09:58:07.343Z
Answer is still useful developers wanting a quick understanding of P2WPKH addresses
Jus12
CC BY-SA 4.0
2019-12-11T16:14:10.230Z
2019-12-11T16:36:05.417Z
2019-12-11T16:36:05.417Z
MCCCS
<p>There’s no conversion of address formats in Bitcoin and attempting to do so will result in loss of funds. </p>

CC BY-SA 4.0
2019-12-11T15:55:47.433Z
2019-12-11T15:55:47.433Z
Claris
<p>I know that similar tools exist for BCH (e.g. <a href="https://cashaddr.bitcoincash.org/" rel="nofollow noreferrer">https://cashaddr.bitcoincash.org/</a>). Is there a way to convert a native segwit bech32 <em>Bitcoin</em> address to a legacy format?</p>

<segregated-witness><bech32-address>
Convert bech32 Bitcoin address to legacy
tristantzara
# Convert bech32 Bitcoin address to legacy

(Asked by: username_0 on 2019-12-11)

I know that similar tools exist for BCH (e.g. <https://cashaddr.bitcoincash.org/>). Is there a way to convert a native segwit bech32 *Bitcoin* address to a legacy format?

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


---

## 3 answers

### Answer by username_1 on 2019-12-11. Score: 8

As Anonymous says, you simply cannot.

I'll try to highlight the important part of username_2's answer:

* In Bitcoin Cash, cashaddr ("bitcoincash:...", similar to, but not quite bech32) and legacy addresses ("1..." and "3...", base58) are two different ways of representing **the same onchain output** in a human-readable way. One can be converted into the other because the resulting transaction will be identical, and the recipient can't tell which address you used.
* In Bitcoin, native segwit addresses ("bc1...", bech32) and legacy addresses ("1..." and "3...", base58) are addresses for **distinct on-chain outputs**. The first are used for BIP141 segwit outputs, while the second are not. The fact that one can be technically converted into the other is irrelevant. If the recipient gave you a native segwit address, it means he expects a transaction that pays to such an output, and he might not recognize a transaction that does anything else. In certain cases, he may be literally unable to access coins sent elsewhere (e.g. because he uses an HSM that can only sign certain transactions).

Short answer: if you're given a native segwit address, and are unable to send to that, there is only one course of action: ask the recipient for legacy address instead.


---

### Answer by username_2 on 2019-12-11. Score: 4

*This answer is about the differences between address formats and what causes incompatibilities.* **If you don't code your wallet, don't trust your wallet about recognizing different addresses made from the same public key! Don't experiment with anything I've said with real money!**

In Bitcoin Cash, CashAddr and 1 addresses are different ways to encode the public key hash for Pay-2-Public-Key-Hash. To spend P2PKH outputs, the public key is revealed, for which a signature is signed. **How the public key hash is serialized doesn't change how the output is spent or created**. Thus those addresses are convertible.

Here are the information Bech32 (P2WPKH), SegWit in P2SH (P2SH-P2WPKH) and 1 addresses keep:

* P2PKH contains the `<20-byte-key-hash>`
* P2WPKH contains the `<20-byte-key-hash>`
* P2SH-P2WPKH contains the hash of the script `0 <20-byte-key-hash>`

Does that mean P2PKH and P2WPKH are the same? No, sending money to the P2PKH and the Bech32 of the same public key will yield different transactions. And how the payee's wallet will spend it with the corresponding private key will be different too. But it's the same private key, the wallet should be able to spend both! When a wallet generated a **Bech32 address** for example, there's nothing that requires the wallet to scan for the transactions spending to that public key as **P2PKH** or **P2SH-P2WPKH**. This will depend on the implementation. (BTW, in P2PKH a compressed or uncompressed public key can be used. P2WPKH or P2SH-P2WPKH can't be used with an uncompressed public key)

For P2WPKH and P2SH-P2WPKH, similar to the previous case, from P2WPKH you can craft a P2SH-P2WPKH, and use it if the payee's wallet is compatible (I don't know about Bitcoin Core but there's no reason a lightweight wallet to be compatible with this). On the other hand, if you see one's P2SH-P2WPKH, you can't derive the P2WPKH or P2PKH unless that address has spent. This is related to hashing once, appending a zero, hashing again. When spent, the public key (and it's hash) are exposed.

Summary: It's theoretically possible but no implementation will be compatible.

> **Comments:**
> **username_3**: This is poor advice to even suggest that wallets are able to spend funds to addresses they didn’t generate. People have done this and lost money.  
> **username_2**: I agree, experienced developers whom I thought my answer could be helpful do not need my answer and users can be misdirected. I'll add warnings.  
> **username_4**: Have you tried this on the testnet?  
> **username_5**: Answer is still useful developers wanting a quick understanding of P2WPKH addresses  

---

### Answer by username_3 on 2019-12-11. Score: 3

There’s no conversion of address formats in Bitcoin and attempting to do so will result in loss of funds.


---

