Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: llethe on January 10, 2020, 08:56:16 AM



Title: Finding the Appropriate Limit Count for Extended Address Search
Post by: llethe on January 10, 2020, 08:56:16 AM
Hello
I have a question while implementing along blockchain bip32.
I understand that bip32 can generate infinite addresses such as m / 0, m / 1, m / 9999 ..
I am wondering if there is a fixed rule to search the line when searching the blockchain full node for keys expanded by bip32 such as xpub in blockchain explorer.

It's not going to search all the infinite addresses, but if you know, please help.


Title: Re: Finding the Appropriate Limit Count for Extended Address Search
Post by: pooya87 on January 10, 2020, 09:13:38 AM
there are no rules, when it comes to BIP32 and all the additions (BIP39, 44, 49,...) every wallet is doing pretty much its own thing although they share a lot of similarities.

there are two main parts in checking child keys:
1. the derivation path.
which should be set by the user: m/0/1/2 or m/44'/0/1 or ... for example. because derivation paths differ from wallet to wallet.

2. the number of child keys to generate.
again this depends on the wallet. usually they generate something between 10 and 20 keys and when a key is used a new one is automatically generated. for example if you use 3 addresses from the first 10, you'll have 13 total addresses generated (from 0 to 12 index).
that same logic is applied when a new master key is imported in the wallet. they check the first n keys then if m of them had balance they also check n+m keys and so on.
they also add some functionality for the user to set this limit (called gap limit in Electrum for example) so that the number of addresses to check can be manually set.


Title: Re: Finding the Appropriate Limit Count for Extended Address Search
Post by: llethe on January 10, 2020, 09:27:18 AM
Then, when the electrum wallet loads a new xpub, or when the blockchain explorer retrieves the entire transaction or address by referring to the master public key,
Is it reading way from m / 0 and stopping if there is no balance or transaction?
For example, the 30th time, if there is no balance or transaction in the retrieved child key, it stops.


Title: Re: Finding the Appropriate Limit Count for Extended Address Search
Post by: mocacinno on January 10, 2020, 09:29:21 AM
Electrum uses a gap limit. When they detect an address is being funded, it makes sure it derives and monitors the next (gap limit) addresses aswell.

For example, if the gap limit is 50, a new wallet only contains unfunded addresses, so electrum will derive and monitor transactions for the first 50 addresses.
If the first address gets funded, electrum will derive and monitor the first 51 addresses.
If you manually pick and send the 10th address and it gets funded, electrum will derive and monitor the first 61 addresses.

If you create a wallet, change the gap limit to 100, manually pick the 99th address and it gets funded, then decrease the gap limit to 50 and restore the wallet from seed, the funded address will no longer be monitored by electrum untill you've funded address 48 (and because of the gap limit, electrum will now derive and monitor address up untill 99).


Title: Re: Finding the Appropriate Limit Count for Extended Address Search
Post by: pooya87 on January 10, 2020, 09:41:46 AM
Is it reading way from m / 0 and stopping if there is no balance or transaction?
For example, the 30th time, if there is no balance or transaction in the retrieved child key, it stops.

yes, assuming m is the child extended key not the main master key.
and yes if none of the first 30 addresses were ever used (they may have been used and have a balance of zero), it just stops there assuming 30 is the predefined limit.


Title: Re: Finding the Appropriate Limit Count for Extended Address Search
Post by: llethe on January 10, 2020, 11:18:07 AM
Thanks for All your answer.

Finally I found out that How discovery works on this location and in yours answer, too


'''
(https://github.com/dan-da/hd-wallet-addrs)
In plain english, discovery works by mathematically deriving the addresses for your wallet in order and checking if each one has been used or not.

A slightly more technical description of the process:

starting from the extended public key (xpub)
for receive addresses, then change addresses
derive batches of xpub child addresses (bip32: 0/*)
for each batch
check if each address has received funds (API call to oracle/server)
until 20 (default) unused addresses in a row are found.
'''


thanks so much