<blockquote>
<ol>
<li>Am I right, is this a derivation path for a Bitcoin wallet that follows this standard?</li>
</ol>
</blockquote>
<p>Close. There is also an account level in between.</p>
<p>Also, there is no distinction between receive and change <em>transactions</em>. Generally, every transaction will have both receive and change <em>outputs</em> 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.</p>
<blockquote>
<ol start="2">
<li>Is this how BIP44 wallets search for funds? Those keys for which there are funds (UTXO) will save the rest just discard (for now)?</li>
</ol>
</blockquote>
<p>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.</p>
<p>Also, BIP44 doesn't really specify how a wallet should work; it just defines what its keys are.</p>
<blockquote>
<ol start="3">
<li>By BIP44 keys are always non-hardened?</li>
</ol>
</blockquote>
<p>The last derivation step is non-hardened. The first three derivation steps from the root are hardened, however.</p>
<blockquote>
<ol start="4">
<li>Number of keys defined by BIP44 is 2 * 2^31? (main question)</li>
</ol>
</blockquote>
<p>Per account, yes; 2<sup>31</sup> internal (change) ones and 2<sup>31</sup> external (receive) ones. Given that in all of Bitcoin's history there have been less than 2<sup>30</sup> 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.</p>
<blockquote>
<ol start="5">
<li>Is the property of extended public keys for address_index keys &quot;invalidated&quot; by using this standard?</li>
</ol>
</blockquote>
<p>I'm not sure I understand your question. If you have the xpub corresponding to the <code>m / 44' / 0' / 0'</code> 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 <code>m</code> or <code>m / 44'</code>, that is worthless as you need the private key too to compute hardened descendants.</p>

CC BY-SA 4.0
2023-07-19T14:19:53.407Z
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
CC BY-SA 4.0
2023-07-19T14:23:09.993Z
(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
CC BY-SA 4.0
2023-07-19T14:30:02.573Z
(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
CC BY-SA 4.0
2023-07-19T14:32:04.270Z
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
CC BY-SA 4.0
2023-07-19T14:34:15.770Z
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
CC BY-SA 4.0
2023-07-19T14:35:22.197Z
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
CC BY-SA 4.0
2023-07-19T14:38:44.027Z
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
CC BY-SA 4.0
2023-07-19T14:45:46.213Z
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
CC BY-SA 4.0
2023-07-19T14:45:59.703Z
@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
CC BY-SA 4.0
2023-07-19T14:57:04.993Z
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
CC BY-SA 4.0
2023-07-19T15:01:58.360Z
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
CC BY-SA 4.0
2023-07-19T15:08:22.817Z
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
CC BY-SA 4.0
2023-07-19T15:18:21.270Z
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
CC BY-SA 4.0
2023-07-19T15:28:05.793Z
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
CC BY-SA 4.0
2023-07-19T15:28:38.833Z
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/147333/discussion-between-pieter-wuille-and-filip).
Pieter Wuille
CC BY-SA 4.0
2023-07-19T13:59:44.337Z
2023-07-19T14:49:18.833Z
2023-07-19T14:49:18.833Z
Pieter Wuille
<p>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.</p>
<p>The Master Bitcoin says that BIP-44 specifies the tree structure of keys (therefor addresses) as follows:</p>
<pre><code>m / purpose' / coin_type' / account' / change / address_index
</code></pre>
<p>So for Bitcoin, according to this standard, it would be <code>m / 44' / 0' / 0'</code> followed by <code>0</code> for &quot;external transactions&quot; (receiving funds) or <code>1</code> for &quot; internal transactions&quot; (change transactions).</p>
<p><strong>1. Am I right, is this a derivation path for a Bitcoin wallet that follows this standard?</strong></p>
<p>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.</p>
<p><strong>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)?</strong></p>
<p>Also, since <code>address_index</code> is written in standard without <code>`</code>, keys are always non-hardened derived.</p>
<p><strong>3. By BIP44 keys are always non-hardened?</strong></p>
<p>If everything written above is correct, does this mean that according to this standard there is a limit to the number of keys?</p>
<p><strong>4. Number of keys defined by BIP44 is 2 * 2^31? (main question)</strong></p>
<p>The final question is whether this standard somehow &quot;invalidates&quot; xpub's ability of generating the child's public keys without knowing the parent private key. I mean, if <code>address_index</code> 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 <code>address_index</code> keys. I mean, this will only make sense if xpub is given from the <code>change</code> level.</p>
<p><strong>5. Is the property of extended public keys for <code>address_index</code> keys &quot;invalidated&quot; by using this standard?</strong></p>

<bip32-hd-wallets><address-generation><bip44><hardened-derivation>
Does BIP44 limit the maximum number of keys? (and some related questions)
dassd
# Does BIP44 limit the maximum number of keys? (and some related questions)

(Asked by: username_0 on 2023-07-18)

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

**Tags:** bip32-hd-wallets, address-generation, bip44, hardened-derivation


---

## 1 answers

### Answer by username_1 on 2023-07-19. Score: 2 | Accepted answer

> 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.

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

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.

> 3. 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.

> 4. 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.

> 5. 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.

> **Comments:**
> **username_0**: 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?  
> **username_1**: (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).  
> **username_0**: (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.  
> **username_0**: 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?  
> **username_0**: 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  
> **username_1**: 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.  
> **username_0**: 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?  
> **username_0**: 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.  
> **username_1**: @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.  
> **username_0**: 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?  
> **username_1**: 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.  
> **username_0**: 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.  
> **username_1**: 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.  
> **username_0**: 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?  
> **username_1**: Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/147333/discussion-between-username_1-username_1-and-filip).  

---

