<blockquote>
  <p>Does it just try all possible addresses related to that seed's master key ? (This seems impractical imo).</p>
</blockquote>

<p>No, this is actually impossible to do since there is effectively an infinite number of addresses that can be generated from a single master private key.</p>

<p>Instead wallets generate keys at standardized derivation paths and assume that other wallets follow the same standards. This is generally a safe assumption. Wallets that do not follow the standard derivation paths usually have documentation stating what derivation paths they use so that you can specify in another wallet what derivation paths to use.</p>

<p>Most wallets follow the <a href="https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki" rel="nofollow noreferrer">BIP 44</a> specification for derivation paths.</p>

<blockquote>
  <p>Are there standards on the max nth of address to generate from the wallet side ?</p>
</blockquote>

<p>No. Typically wallets generate addresses until they have generated <code>n</code> unused addresses (known as the gap limit). The gap limit is not standardized and many wallets allow you to configure it. In many wallets, the gap limit is 20 keys, however this probably is not sufficient when restoring. In other wallets, it can be 100 keys, and others 1000.</p>

CC BY-SA 4.0
2018-06-10T21:33:21.463Z
Excellent reply. 
I have a couple of questions: 

1. Does that mean for each extended private key a wallet software developer might expect 20 to 1000 addresses to recover when designing a new software wallet.

2. Can't that be a constraint when the idea of keeping keys locally and the size of the smartphone device with hundred of thousands of generated extended private keys ?

Thanks again for your reply.
Eddy
CC BY-SA 4.0
2018-06-10T22:06:48.043Z
1. Yes. 2. No, keys can be dynamically generated and do not have to be stored. Also they are very small and requires hundreds of thousands of keys to get anywhere to taking up a truly noticeable amount of space.
Ava Chow
CC BY-SA 4.0
2018-06-11T00:16:58.617Z
__Typically wallets generate addresses until they have generated n unused addresses__

Does that mean the software wallet has to do a full blockchain scan to check whether the address is unused ?
Eddy
CC BY-SA 4.0
2018-06-11T04:23:29.820Z
Yes, wallets will need to scan the blockchain. However a full rescan for each private key is unnecessary as people typically use addresses in order. This means that the same rescan can be used and new keys generated as old ones are used. It is unlikely that the newly generated keys will have been used before a key that was already known, especially if the gap limit is large.
Ava Chow
CC BY-SA 4.0
2018-06-11T22:28:25.077Z
Please allow me to summarize my understanding here, you'll tell me whether I'm still getting something wrong.

The way I understand these problems are solved is from an extended private key, visit siblings addresses from index 0 to n if you find a 20 address gap we go deep another address generation starting from the kids of the 0th child and repeat the same things till the gap is filled from the generational level from the tree perspective ?
If ~20 is the gap limit from the siblings addresses, what's considered as a gap limit from the parent to child relationship ?
Eddy
CC BY-SA 4.0
2018-06-11T23:20:32.100Z
The gap limit only applies to the sibling keys. There is no gap limit from parent to child keys. We do not search through deeper and deeper levels, we only search at most 2 levels with the starting point being assumed to match a standard derivation path. For example, if we assume BIP 44, we would start with the key at m/44'/0'/0'/0/0. We would also search m/44'/0'/0'/1/0. However we do not search any other levels.
Ava Chow
CC BY-SA 4.0
2018-06-10T21:26:01.897Z
2018-06-10T21:26:01.897Z
Ava Chow
<p>I have been reading the BIP32 proposal explaining how HD works but it didn't mention on any point how one wallet in one phone can recover from a simple mnemonic seed.</p>

<ol>
<li><p>Does it just try all possible addresses related to that seed's master key by doing the entire blockchain look up for addresses at the same time ? (This seems impractical imo).</p></li>
<li><p>Are there standards on the max nth of address to generate from the wallet side ?</p></li>
</ol>

<wallet><bip32-hd-wallets><mnemonic-seed><bip44>
In HD Wallet recovery how does the wallets know which addresses to recover
Eddy
# In HD Wallet recovery how does the wallets know which addresses to recover

(Asked by: username_0 on 2018-06-10)

I have been reading the BIP32 proposal explaining how HD works but it didn't mention on any point how one wallet in one phone can recover from a simple mnemonic seed.

1. Does it just try all possible addresses related to that seed's master key by doing the entire blockchain look up for addresses at the same time ? (This seems impractical imo).
2. Are there standards on the max nth of address to generate from the wallet side ?

**Tags:** wallet, bip32-hd-wallets, mnemonic-seed, bip44


---

## 1 answers

### Answer by username_1 on 2018-06-10. Score: 3

> Does it just try all possible addresses related to that seed's master key ? (This seems impractical imo).

No, this is actually impossible to do since there is effectively an infinite number of addresses that can be generated from a single master private key.

Instead wallets generate keys at standardized derivation paths and assume that other wallets follow the same standards. This is generally a safe assumption. Wallets that do not follow the standard derivation paths usually have documentation stating what derivation paths they use so that you can specify in another wallet what derivation paths to use.

Most wallets follow the [BIP 44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) specification for derivation paths.

> Are there standards on the max nth of address to generate from the wallet side ?

No. Typically wallets generate addresses until they have generated `n` unused addresses (known as the gap limit). The gap limit is not standardized and many wallets allow you to configure it. In many wallets, the gap limit is 20 keys, however this probably is not sufficient when restoring. In other wallets, it can be 100 keys, and others 1000.

> **Comments:**
> **username_0**: Excellent reply.  I have a couple of questions:   1. Does that mean for each extended private key a wallet software developer might expect 20 to 1000 addresses to recover when designing a new software wallet.  2. Can't that be a constraint when the idea of keeping keys locally and the size of the smartphone device with hundred of thousands of generated extended private keys ?  Thanks again for your reply.  
> **username_1**: 1. Yes. 2. No, keys can be dynamically generated and do not have to be stored. Also they are very small and requires hundreds of thousands of keys to get anywhere to taking up a truly noticeable amount of space.  
> **username_0**: __Typically wallets generate addresses until they have generated n unused addresses__  Does that mean the software wallet has to do a full blockchain scan to check whether the address is unused ?  
> **username_1**: Yes, wallets will need to scan the blockchain. However a full rescan for each private key is unnecessary as people typically use addresses in order. This means that the same rescan can be used and new keys generated as old ones are used. It is unlikely that the newly generated keys will have been used before a key that was already known, especially if the gap limit is large.  
> **username_0**: Please allow me to summarize my understanding here, you'll tell me whether I'm still getting something wrong.  The way I understand these problems are solved is from an extended private key, visit siblings addresses from index 0 to n if you find a 20 address gap we go deep another address generation starting from the kids of the 0th child and repeat the same things till the gap is filled from the generational level from the tree perspective ? If ~20 is the gap limit from the siblings addresses, what's considered as a gap limit from the parent to child relationship ?  
> **username_1**: The gap limit only applies to the sibling keys. There is no gap limit from parent to child keys. We do not search through deeper and deeper levels, we only search at most 2 levels with the starting point being assumed to match a standard derivation path. For example, if we assume BIP 44, we would start with the key at m/44'/0'/0'/0/0. We would also search m/44'/0'/0'/1/0. However we do not search any other levels.  

---

