0

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?

3

As Anonymous says, you simply cannot.

I'll try to highlight the important part of MCCCS'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.

| improve this answer | |
2

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

| improve this answer | |
0

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.

| improve this answer | |
  • 1
    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. – Anonymous Dec 11 '19 at 16:26
  • 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 Dec 11 '19 at 16:33

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.