My main question is actually the one in the title. However, for the sake of consistency, I asked some more questions along the way, in order to create a certain story and somehow put everything in one place. All questions are related to the BIP44 standard and the main question.
The Master Bitcoin says that BIP-44 specifies the tree structure of keys (therefor addresses) as follows:
m / purpose' / coin_type' / account' / change / address_indexSo for Bitcoin, according to this standard, it would be m / 44' / 0' / 0' followed by 0 for "external transactions" (receiving funds) or 1 for " internal transactions" (change transactions).
1. Am I right, is this a derivation path for a Bitcoin wallet that follows this standard?
Therefore, following this standard, Bitcoin wallets will first create the 45th child from the master key through hardened derivation, then from it again through hardened derivation the first child, and then through normal (non-hardened) derivation the first (index 0) and the second child (index 1). After that, it will go through all normal (non-hardened) derived children (2^31) from the previous two children to search the UTXOs. Of course, if a sufficient number of consecutive keys (defined through the gap limit), i.e. addresses, which do not have a UTXO, the search stops.
2. Is this how BIP44 wallets search for funds? Those keys for which there are funds (UTXO) will save the rest just discard (for now)?
Also, since address_index is written in standard without `, keys are always non-hardened derived.
3. By BIP44 keys are always non-hardened?
If everything written above is correct, does this mean that according to this standard there is a limit to the number of keys?
4. Number of keys defined by BIP44 is 2 * 2^31? (main question)
The final question is whether this standard somehow "invalidates" xpub's ability of generating the child's public keys without knowing the parent private key. I mean, if address_index is the last layer the wallet looks at, then giving xpub from that level of the tree will have no effect by this standard because the wallet won't even look at the descendants of the address_index keys. I mean, this will only make sense if xpub is given from the change level.
5. Is the property of extended public keys for address_index keys "invalidated" by using this standard?
