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?

dassd
  • 1,069
  • 1
  • 4
  • 21

1 Answers1

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.

Pieter Wuille
  • 105,497
  • 9
  • 194
  • 308
  • 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 '23 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 '23 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 '23 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 '23 at 14:32
  • I know that the standard does not define the search for funds, but I want to say that only for those keys (keys generated according to that standard), in the case of BIP44 only for the address_index level of the keys, related UTXO will be searched – dassd Jul 19 '23 at 14:34
  • Yes, through some mechanism the wallet will search for transactions that interact with the P2PKH addresses corresponding to some subset of the BIP44 derived leaf keys, if it's a BIP44 compatible wallet. If it's a BIP84 compatible wallet, it'll use the P2WPKH addresses corresponding to BIP84 derived leaf keys. But I don't think there is much software that is purely BIP44 (or purely BIP84), and there is nothing that prevents wallets from supporting multiple or more generic derivation paths. – Pieter Wuille Jul 19 '23 at 14:35
  • Yes, that's what I meant, sorry if I didn't express myself well and potentially confused you. So in the context of BIP44 only transactions related to address_index level of the keys will be searched? – dassd Jul 19 '23 at 14:38
  • Regarding your edited comment. Yes, I know there isn't much software that is BIP44 only or BIP84 only, but what I'm saying is that wallets follow any of the standards or more (as many as they support) and then find the keys for the last level (I assume it's always the last level) from the given standard and see if they have transactions associated with that keys. As I explained for BIP44, the same applies to other standards that the wallet supports. – dassd Jul 19 '23 at 14:45
  • @Filip Ah, if your question is whether only addresses corresponding the leaf keys are looked for: yes - the other levels are just intermediary for the purpose of deriving keys. See BIP32 for this sort of stuff (which specifies hierarchical key derivation in general). BIP44 is just a proposed standard way of picking derivation paths. – Pieter Wuille Jul 19 '23 at 14:45
  • Well my question is: the wallet will use BIP32 to generate keys from seed but the way it generates will take from BIP44 or BIP84 or something similar. For example, if wallet follows only BIP44 it will generate only 45th child from master key using hardened derivation. If it also follow BIP84, it will generate also 85th child from master key using hardened derivation and so on following the standard. At the end, when it comes to the leaf keys, it will try to find some subset of these keys that have related UTXOs (respecting gap limit). I hope I have explained well now what I mean? Am I right? – dassd Jul 19 '23 at 14:57
  • I think the answer to your question is yes, but maybe I still misunderstand because what you ask I think boils down to "does a wallet generate the keys for its addresses (according to whatever standard that says what those keys/addresses are)?", which is trivially true, as I can't imagine what alternative you could be thinking of of how it could work. – Pieter Wuille Jul 19 '23 at 15:01
  • Maybe I shouldn't have used the term address, just the term keys. If we are looking at P2PKH, then I meant the address obtained by passing the public key through SHA512-RIPEMB160 and getting the address. If we forget that I used the term address at all, but only keys, then is this all correct? Let's say we are looking for associated UTXOs for leaf-level keys instead of addresses. – dassd Jul 19 '23 at 15:08
  • Associating UTXOs with keys is not well-defined, as there are potentially an infinite number of ways of turning keys into addresses, and wallets are not looking for all of them. Wallets decide how to generate keys (nearly always through some subset of BIP32 derivation paths), and what corresponding address(es) to support, and then look for transactions to pay those addresses. Standards like BIP44 and BIP84 define what those subsets are, which wallets may choose to support or not support. – Pieter Wuille Jul 19 '23 at 15:18
  • Yes, that's exactly what I'm talking about. So, one follows a path defined in one of the standards (BIP44/84...), gets to the leaf keys, and then looks at the associated transactions for them, respecting the gap limit. So if a wallet only follows BIP44 it will generate 45th children from master key via hardened derivation, if it also follows BIP84 it will also generate 85th children from master key. Then, by BIP44, wallet will generate the first (index 0) hardened child from previously 45th child in second layer and so on until the child leaf for which the transaction will be requested. Right? – dassd Jul 19 '23 at 15:28
  • 1
    Let us continue this discussion in chat. – Pieter Wuille Jul 19 '23 at 15:28