<p><a href="https://en.bitcoin.it/wiki/BIP_0032" rel="nofollow noreferrer">BIP-32</a> says</p>
<blockquote>
<p>In the example of a webshop, the webserver does not need access to all public keys of the merchant's wallet; only to those addresses which are used to receive customer's payments, and not for example the change addresses that are generated when the merchant spends money. Hierarchical deterministic wallets allow such selective sharing by supporting multiple keypair chains, derived from a single root.</p>
</blockquote>
<p>The network doesn't care. It doesn't distinguish the two. Any address (i.e. locking script) can be used or reused for either purpose.</p>
<p>Your wallet might care though.</p>

CC BY-SA 4.0
2023-03-24T10:14:28.053Z
2023-03-24T10:14:28.053Z
RedGrittyBrick
<p>This distinction only exists for the internal processes of your wallet, and to provide a better UX to the user.</p>
<p>Consider for example when you request a payment. You generate a receive address, the sender creates a transaction to pay you. The transaction creates a recipient output that assigns the payment to your receive address. Your wallet will now show this payment in your “Receive” tab.</p>
<p>On the other hand, when you make a payment, your transaction might have two outputs. One recipient output to make the payment, and a change output to return the remainder of the funds from the inputs to your own wallet. The change address to receive the change output was created on the fly by your wallet when it created the payment transaction. The change address and change output will <em>not</em> show up in your “Receive” tab, because you transferred funds from your left pocket to your right pocket. Rather the transaction will show up in your “Send” tab.</p>
<p>Your wallet might also use a different approach when scanning receive and change addresses. While you might give out a receive address, but never receive a payment to it, almost every change address on the subchain will be used, since they are only generated on the fly when you are already making a payment.</p>
<p>So, while they work exactly the same under the hood and there is no mechanical issue using one or the other for the opposite purpose, in regard to actually receiving the funds, your wallet software may operate under some assumptions regarding the purpose of the addresses that could impact your UX. I would recommend using the addresses per the purpose that they are meant to have.</p>

CC BY-SA 4.0
2023-03-24T15:05:27.713Z
2023-03-24T15:13:44.710Z
2023-03-24T15:13:44.710Z
Murch
<p>I see receiving address and change address in wallet client and bip44. Why distinguish between receiving address and change address?</p>
<p>What will be the problem if I use only change address chain for receiving and changing, or use only receiving address chain for receiving and changing?</p>

<wallet><address><change><receiving><bip44>
Why distinguish between receiving address and change address
MonKong
# Why distinguish between receiving address and change address

(Asked by: username_0 on 2023-03-24)

I see receiving address and change address in wallet client and bip44. Why distinguish between receiving address and change address?

What will be the problem if I use only change address chain for receiving and changing, or use only receiving address chain for receiving and changing?

**Tags:** wallet, address, change, receiving, bip44


---

## 2 answers

### Answer by username_1 on 2023-03-24. Score: 0 | Accepted answer

[BIP-32](https://en.bitcoin.it/wiki/BIP_0032) says

> In the example of a webshop, the webserver does not need access to all public keys of the merchant's wallet; only to those addresses which are used to receive customer's payments, and not for example the change addresses that are generated when the merchant spends money. Hierarchical deterministic wallets allow such selective sharing by supporting multiple keypair chains, derived from a single root.

The network doesn't care. It doesn't distinguish the two. Any address (i.e. locking script) can be used or reused for either purpose.

Your wallet might care though.


---

### Answer by username_2 on 2023-03-24. Score: 1

This distinction only exists for the internal processes of your wallet, and to provide a better UX to the user.

Consider for example when you request a payment. You generate a receive address, the sender creates a transaction to pay you. The transaction creates a recipient output that assigns the payment to your receive address. Your wallet will now show this payment in your “Receive” tab.

On the other hand, when you make a payment, your transaction might have two outputs. One recipient output to make the payment, and a change output to return the remainder of the funds from the inputs to your own wallet. The change address to receive the change output was created on the fly by your wallet when it created the payment transaction. The change address and change output will *not* show up in your “Receive” tab, because you transferred funds from your left pocket to your right pocket. Rather the transaction will show up in your “Send” tab.

Your wallet might also use a different approach when scanning receive and change addresses. While you might give out a receive address, but never receive a payment to it, almost every change address on the subchain will be used, since they are only generated on the fly when you are already making a payment.

So, while they work exactly the same under the hood and there is no mechanical issue using one or the other for the opposite purpose, in regard to actually receiving the funds, your wallet software may operate under some assumptions regarding the purpose of the addresses that could impact your UX. I would recommend using the addresses per the purpose that they are meant to have.


---

