0

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_index

So 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?

Improve this question

1 Answer 1

Reset to default
2
  1. Am I right, is this a derivation path for a Bitcoin wallet that follows this standard?

Close. There is also an account level in between.

Also, there is no distinction between receive and change transactions. Generally, every transaction will have both receive and change outputs however. The difference is that the receive outputs are to addresses created by the recipient, and change outputs are back to the sender, and added by the sender software itself.

  1. Is this how BIP44 wallets search for funds? Those keys for which there are funds (UTXO) will save the rest just discard (for now)?

The first 43 hardened descendants of the root are not discarded typically; they're just never computed. You can immediately compute hardened child 44' from the root without computing the other ones. See BIP32 for details.

Also, BIP44 doesn't really specify how a wallet should work; it just defines what its keys are.

  1. By BIP44 keys are always non-hardened?

The last derivation step is non-hardened. The first three derivation steps from the root are hardened, however.

  1. Number of keys defined by BIP44 is 2 * 2^31? (main question)

Per account, yes; 231 internal (change) ones and 231 external (receive) ones. Given that in all of Bitcoin's history there have been less than 230 transactions in total, that ought to be sufficient for a single wallet. BIP44 also supports multiple accounts, which each have this many numbers. Further, nothing prevents wallet from supporting more keys than just the BIP44 ones.

  1. Is the property of extended public keys for address_index keys "invalidated" by using this standard?

I'm not sure I understand your question. If you have the xpub corresponding to the m / 44' / 0' / 0' node you can compute all leaf public keys under it (so all keys for both internal and external). If you only have the xpub for m or m / 44', that is worthless as you need the private key too to compute hardened descendants.

Improve this answer
15
  • 1. Yes, I forgot account level (I will edit it) 2. Yes, I got it, but that is the way (as I described) for wallets that support only BIP44 to find all funds? 3. Aren't the last two non-hardened and the first 3 hardened? 5. I didn't express myself well. I was going to say that XPUB doesn't make sense in the case of address_index key level since the children of these keys won't even be searched by BIP44. It makes sense in BIP44 only to give XPUB from change and account level?
    – dassd
    Jul 19 at 14:19
  • (2) As opposed to what? BIP44 just specifies the keys, not how a wallet finds the addresses. There is a ton more going on to discovering transactions which is unrelated, so it's hard to answer "is this how it works in practice", and it's not specific to BIP44 (3) Yes indeed, 3 hardended, 2 unhardened. (5) xpubs for leaves of the tree are pointless in general (independent from BIP44).
    – Pieter Wuille
    Jul 19 at 14:23
  • (2) I know that BIP44 explains the keys, not how the wallet searches for addresses. But if the wallet follows the BIP44 standard (let's say only it; not BIP84 or anything else), it will find/generate all the keys (addresses) in the way I described and see if there are UTXOs related to them? In other words, UTXO will be searched only for them, respecting the gap limit, not for other keys.
    – dassd
    Jul 19 at 14:30
  • On the other hand, if it follows, for example 84, it will generate keys according to that standard and see if there is any UTXOs for that keys?
    – dassd
    Jul 19 at 14:32
  • 1
    Let us continue this discussion in chat.
    – Pieter Wuille
    Jul 19 at 15:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.