My fundamental query is definitely the one within the title. Nonetheless, for the sake of consistency, I requested some extra questions alongside the way in which, with a purpose to create a sure story and in some way put every little thing in a single place. All questions are associated to the BIP44 commonplace and the primary query.
The Grasp Bitcoin says that BIP-44 specifies the tree construction of keys (therefor addresses) as follows:
m / objective' / coin_type' / account' / change / address_index
So for Bitcoin, based on this commonplace, it could be m / 44' / 0' adopted by 0 for “exterior transactions” (receiving funds) or 1 for ” inside transactions” (change transactions).
1. Am I proper, is that this a derivation path for a Bitcoin pockets that follows this commonplace?
Subsequently, following this commonplace, Bitcoin wallets will first create the forty fifth baby from the grasp key by hardened derivation, then from it once more by hardened derivation the primary baby, after which by regular (non-hardened) derivation the primary (index 0) and the second baby (index 1). After that, it’ll undergo all regular (non-hardened) derived kids (2^31) from the earlier two kids to go looking the UTXOs. In fact, if a enough variety of consecutive keys (outlined by the hole restrict), i.e. addresses, which should not have a UTXO, the search stops.
2. Is that this how BIP44 wallets seek for funds? These keys for which there are funds (UTXO) will save the remainder simply discard (for now)?
Additionally, since address_index is written in commonplace with out `, keys are at all times non-hardened derived.
3. By BIP44 keys are at all times non-hardened?
If every little thing written above is right, does this imply that based on this commonplace there’s a restrict to the variety of keys?
4. Variety of keys outlined by BIP44 is 2 * 2^31? (fundamental query)
The ultimate query is whether or not this commonplace in some way “invalidates” xpub’s capability of producing the kid’s public keys with out realizing the mum or dad personal key. I imply, if address_index is the final layer the pockets appears at, then giving xpub from that degree of the tree can have no impact by this commonplace as a result of the pockets will not even have a look at the descendants of the address_index keys. I imply, it will solely make sense if xpub is given from the change degree.
5. Is the property of prolonged public keys for address_index keys “invalidated” by utilizing this commonplace?