<p>Read BIP39 then BIP32 then BIP44</p>
<blockquote>
<p>Seed is used to generate Master Private Key (and the mnemonic 12/24 words).</p>
</blockquote>
<p>Better way to think, convert the entropy to a BIP39 mnemonic. Use that mnemonic plus a (technically optional but no) passphrase as the inputs to produce the BIP39 numeric seed. End of BIP39.</p>
<p>The BIP39 numeric seed is used to derive the <strong>extended master</strong> private key (aka master xprv or BIP32 root key, corresponds to the root node &quot;m&quot;)</p>
<p>That xprv includes the master private key plus the chain code</p>
<p>and from that master xprv is derived every child xprv for a given derivation path in the tree below.</p>
<p>The public key and address are derived from the private key. Only extended keys (with a chain code) can derive children.</p>
<p>Accounts are at level 4, so #7 below</p>
<p>m / purpose' / coin_type' / account' / change / address_index</p>
<p>e.g.  m/44'/0'/7'/change/index</p>
<blockquote>
<p>Now my question is: Is it possible to have multiple receiving addresses (bc1q) related to the same PHK, thus to the same account?</p>
</blockquote>
<p>Thus, no, 1:1 with the keypair</p>

CC BY-SA 4.0
2022-02-25T11:19:03.770Z
thanks for the clear answer. I get it. 
Now suppose I have a Ledger HD Wallet with 1 account m/44'/0'/0'
I received two payments on two different addresses. What did the ledger do behind the screen to generate the 2 addresses associated to same account and how? 

My understanding is that from the extended private key of the account m/44'/0'/0' a new child private key is generated and from it is derived a new child public key and its PKH with the human readable **address**. So I get smth like this:
m/44'/0'/7'/0/0 --> bc1q ** first address**
m/44'/0'/7'/0/1 --> bc1q **second address**
Tao
CC BY-SA 4.0
2022-02-26T06:03:14.060Z
the addresses are children of change (internal vs external)
HansBKK
CC BY-SA 4.0
2022-02-26T06:03:44.357Z
they get derived with incrementing index values
HansBKK
CC BY-SA 4.0
2022-02-26T15:49:46.993Z
ok, after reading again the BIP 32 39 and 44, I finally got it. Reading the same concept with different words, helped me a lot. BITCOIN is quite a long and beautiful puzzle to solve :) it seems it's neverending.
Tao
CC BY-SA 4.0
2022-02-25T07:48:05.610Z
2022-02-25T07:48:05.610Z
HansBKK
<p>No, there is a one-to-one relationship between the public key hash and the address. The address is not a short form of the hash, it is actually a human readable form of the hash. The address is an encoding of the hash (and a bit of extra data indicating what to do with it) itself, so there is only one address per public key hash.</p>

CC BY-SA 4.0
2022-02-25T05:37:04.910Z
2022-02-25T05:37:04.910Z
Ava Chow
<p>I am trying to get the big picture of the bitcoin <em>entities</em> starting from seed to btc receiving addresses in Hierarchical deterministic wallets without being too technical about hash functions or too specific about each entity. If there are other entities (like PKH) that should be included in this &quot;Entities relationship diagram&quot;, please let me know.</p>
<p>So trying to summarize the main concepts as I understood them:</p>
<ol>
<li>Seed is used to generate Master Private Key (and the mnemonic 12/24 words).</li>
<li>From Master Private Key, many child private keys can be derived. Together with the derived public keys, they represent the &quot;accounts&quot; in the wallet-family-bank (ex. My Savings account, My Spending account, My son's account etc)</li>
<li>In order to receive payments to a specific account, the PHK (double hashed public key) or the short version of it (bc1q...) needs to be provided to the payer.</li>
</ol>
<p>Now my question is: Is it possible to have multiple receiving addresses (bc1q) related to the same PHK, thus to the same account? As per my understanding from practical experience with Ledger, it is so, but after reading Grokking Bitcoin I got a bit confused.
<a href="https://i.sstatic.net/6Uo8g.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/6Uo8g.png" alt="Big Picture. Entities relationship" /></a></p>

<address><public-key>
Is it possible to have multiple receiving addresses (bc1q) related to the same public key hash
Tao
# Is it possible to have multiple receiving addresses (bc1q) related to the same public key hash

(Asked by: username_0 on 2022-02-24)

I am trying to get the big picture of the bitcoin *entities* starting from seed to btc receiving addresses in Hierarchical deterministic wallets without being too technical about hash functions or too specific about each entity. If there are other entities (like PKH) that should be included in this "Entities relationship diagram", please let me know.

So trying to summarize the main concepts as I understood them:

1. Seed is used to generate Master Private Key (and the mnemonic 12/24 words).
2. From Master Private Key, many child private keys can be derived. Together with the derived public keys, they represent the "accounts" in the wallet-family-bank (ex. My Savings account, My Spending account, My son's account etc)
3. In order to receive payments to a specific account, the PHK (double hashed public key) or the short version of it (bc1q...) needs to be provided to the payer.

Now my question is: Is it possible to have multiple receiving addresses (bc1q) related to the same PHK, thus to the same account? As per my understanding from practical experience with Ledger, it is so, but after reading Grokking Bitcoin I got a bit confused.
[![Big Picture. Entities relationship](https://i.sstatic.net/6Uo8g.png)](https://i.sstatic.net/6Uo8g.png)

**Tags:** address, public-key


---

## 2 answers

### Answer by username_1 on 2022-02-25. Score: 1 | Accepted answer

Read BIP39 then BIP32 then BIP44

> Seed is used to generate Master Private Key (and the mnemonic 12/24 words).

Better way to think, convert the entropy to a BIP39 mnemonic. Use that mnemonic plus a (technically optional but no) passphrase as the inputs to produce the BIP39 numeric seed. End of BIP39.

The BIP39 numeric seed is used to derive the **extended master** private key (aka master xprv or BIP32 root key, corresponds to the root node "m")

That xprv includes the master private key plus the chain code

and from that master xprv is derived every child xprv for a given derivation path in the tree below.

The public key and address are derived from the private key. Only extended keys (with a chain code) can derive children.

Accounts are at level 4, so #7 below

m / purpose' / coin\_type' / account' / change / address\_index

e.g. m/44'/0'/7'/change/index

> Now my question is: Is it possible to have multiple receiving addresses (bc1q) related to the same PHK, thus to the same account?

Thus, no, 1:1 with the keypair

> **Comments:**
> **username_0**: thanks for the clear answer. I get it.  Now suppose I have a Ledger HD Wallet with 1 account m/44'/0'/0' I received two payments on two different addresses. What did the ledger do behind the screen to generate the 2 addresses associated to same account and how?   My understanding is that from the extended private key of the account m/44'/0'/0' a new child private key is generated and from it is derived a new child public key and its PKH with the human readable **address**. So I get smth like this: m/44'/0'/7'/0/0 --> bc1q ** first address** m/44'/0'/7'/0/1 --> bc1q **second address**  
> **username_1**: the addresses are children of change (internal vs external)  
> **username_1**: they get derived with incrementing index values  
> **username_0**: ok, after reading again the BIP 32 39 and 44, I finally got it. Reading the same concept with different words, helped me a lot. BITCOIN is quite a long and beautiful puzzle to solve :) it seems it's neverending.  

---

### Answer by username_2 on 2022-02-25. Score: 0

No, there is a one-to-one relationship between the public key hash and the address. The address is not a short form of the hash, it is actually a human readable form of the hash. The address is an encoding of the hash (and a bit of extra data indicating what to do with it) itself, so there is only one address per public key hash.


---

