In HD Wallet recovery how does the wallets know which addresses to recover

4

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 ?

Eddy

Posted 2018-06-10T21:19:18.073

Reputation: 101

Answers

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 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.

Andrew Chow

Posted 2018-06-10T21:19:18.073

Reputation: 50 267

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 – 2018-06-10T21:33:21.463

>

  • 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.
  • < – Andrew Chow – 2018-06-10T22:06:48.043

    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 – 2018-06-11T00:16:58.617

    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. – Andrew Chow – 2018-06-11T04:23:29.820

    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 – 2018-06-11T22:28:25.077

    1The 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. – Andrew Chow – 2018-06-11T23:20:32.100