<blockquote>
  <p>Is it safe to only give them the option of receiving to a "compatibility" address?</p>
</blockquote>

<p>Yes. All modern wallet software understand P2SH and can create transactions that send to such addresses.</p>

CC BY-SA 4.0
2019-02-28T19:41:59.367Z
What's the implication of displaying both? i.e. for a single compressed public key, you'll have utxo associated with multiple addresses (if people send to both.)
Malone
CC BY-SA 4.0
2019-02-28T20:00:06.437Z
A UTXO is only associated with a single encumberment (script) - The fact that one private key controls multiple outputs is irrelevant. However, you should be using HD wallets to derive keys for BIP44/49/84 following standard paths, in which case they private key will not be common.
Raghav Sood
CC BY-SA 4.0
2019-02-28T20:07:42.003Z
@RaghavSood So even if the address to be generated is p2sh(p2wpkh), I should derive from the HD wallet at say, m / 84' / 0' / 0' / 0 / 0?
Malone
CC BY-SA 4.0
2019-02-28T20:29:17.533Z
Actually I just noticed bip49 refers to this particular example.
Malone
CC BY-SA 4.0
2019-02-28T19:35:23.613Z
2019-02-28T19:35:23.613Z
Ava Chow
<p>Displaying two would be justified if you were asking about a BC1 p2wpkh vs a 3xxx p2sh(p2wpkh) because not everything supports BC1 but its pretty good to use when supported.</p>

<p>Displaying two isn't useful between p2pkh/p2sh as you've asked about because p2sh is supported everywhere and many wallets and services have used p2sh exclusively for a long time.</p>

<p>Supporting plain p2pkh is not something I'd recommend a new wallet bother doing. That development and testing effort would better be spent on newer functionality.</p>

CC BY-SA 4.0
2019-03-02T14:38:51.980Z
2019-03-02T14:38:51.980Z
G. Maxwell
<p>To receive funds, I was thinking of giving a user the option of displaying two QR codes: </p>

<ol>
<li>Legacy - <code>p2phk</code> e.g. <code>1AKDDsfTh8uY4X3ppy1m7jw1fVMBSMkzjP</code></li>
<li>Compatibility - <code>p2sh(p2wpkh)</code> e.g. <code>34nSkinWC9rDDJiUY438qQN1JHmGqBHGW7</code></li>
</ol>

<p>Is it safe to only give them the option of receiving to a "compatibility" address?</p>

<address><segregated-witness><utxo><p2sh><p2pkh>
If I was developing a Bitcoin wallet, should I support both legacy and compatibility addresses?
Malone
# If I was developing a Bitcoin wallet, should I support both legacy and compatibility addresses?

(Asked by: username_0 on 2019-02-28)

To receive funds, I was thinking of giving a user the option of displaying two QR codes:

1. Legacy - `p2phk` e.g. `1AKDDsfTh8uY4X3ppy1m7jw1fVMBSMkzjP`
2. Compatibility - `p2sh(p2wpkh)` e.g. `34nSkinWC9rDDJiUY438qQN1JHmGqBHGW7`

Is it safe to only give them the option of receiving to a "compatibility" address?

**Tags:** address, segregated-witness, utxo, p2sh, p2pkh


---

## 2 answers

### Answer by username_3 on 2019-03-02. Score: 5 | Accepted answer

Displaying two would be justified if you were asking about a BC1 p2wpkh vs a 3xxx p2sh(p2wpkh) because not everything supports BC1 but its pretty good to use when supported.

Displaying two isn't useful between p2pkh/p2sh as you've asked about because p2sh is supported everywhere and many wallets and services have used p2sh exclusively for a long time.

Supporting plain p2pkh is not something I'd recommend a new wallet bother doing. That development and testing effort would better be spent on newer functionality.


---

### Answer by username_1 on 2019-02-28. Score: 2

> Is it safe to only give them the option of receiving to a "compatibility" address?

Yes. All modern wallet software understand P2SH and can create transactions that send to such addresses.

> **Comments:**
> **username_0**: What's the implication of displaying both? i.e. for a single compressed public key, you'll have utxo associated with multiple addresses (if people send to both.)  
> **username_2**: A UTXO is only associated with a single encumberment (script) - The fact that one private key controls multiple outputs is irrelevant. However, you should be using HD wallets to derive keys for BIP44/49/84 following standard paths, in which case they private key will not be common.  
> **username_0**: @username_2 So even if the address to be generated is p2sh(p2wpkh), I should derive from the HD wallet at say, m / 84' / 0' / 0' / 0 / 0?  
> **username_0**: Actually I just noticed bip49 refers to this particular example.  

---

