<p>Most (but not all) wallets will follow what is specified in BIPs <a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki" rel="nofollow noreferrer">32</a>, <a href="https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki" rel="nofollow noreferrer">44</a>, and <a href="https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki" rel="nofollow noreferrer">49</a>.</p>

<p>BIP 32 defines what derivation paths are and what they mean. It is the standard for deriving all of the keys in a HD wallet.</p>

<p>BIPs 44 and 49 specify derivation paths that wallets should use. BIP 44 defines a standard derivation path format: <code>m / purpose' / coin_type' / account' / change / address_index</code>. It also defines the <code>purpose</code> for non-segwit Bitcoin keys. </p>

<p>When a wallet is deriving the keys, the path for external keys, i.e. those keys which you get by clicking "New Receive Address" (or similar) is <code>m/44'/0'/0'/0/i</code> and <code>i</code> is just incremented for new keys.</p>

<p>For internal keys, i.e. keys for change addresses, the derivation path will set the <code>change</code> field to <code>1</code>, so the path will be <code>m/44'/0'/0'/1/i</code> and <code>i</code> is incremented for each new change address that is needed.</p>

<p>Since that <code>change</code> field is essentially a boolean, there is no need to iterate through any indexes other than <code>0</code> and <code>1</code>.</p>

<p>BIP 49 specifies the <code>purpose</code> for keys used for P2SH nested segwit addresses. It just sets the <code>purpose</code> field to be 49, so the derivation paths will be <code>m/49'/0'/0'/k/i</code> where <code>k</code> is the <code>change</code> field and <code>i</code> is the <code>address_index</code>. The <code>change</code> and <code>address_index</code> fields remain the same as defined in BIP 44.</p>

<hr>

<p>It is important to keep in mind that not all wallets follow BIPs 32, 44, and 49. For example, Armory uses its own HD wallet algorithm which predates BIP 32, although BIP 32 support for Armory is currently in the works. Other wallets such as Bitcoin Core and MultiBit HD do not follow BIP 44. Instead they use different derivation paths. For Bitcoin Core it's <code>m/k'/i'</code> where <code>k</code> is <code>change</code> (same definition as with BIP 44) and <code>i</code> is <code>address_index</code> (same definition as with BIP 44).</p>

CC BY-SA 3.0
2018-01-08T07:28:17.953Z
This is a very clear explanation. Thankyou very much. It's enough for me to put the pieces together and also finish off my wallet.
Christian Findlay
CC BY-SA 3.0
2018-01-08T06:54:52.867Z
2018-01-08T06:54:52.867Z
Ava Chow
<p>It appears that there are many way to traverse Bitcoin addresses. I am looking best practice, and I am also looking for the documented logic of how common wallets do it so I can replicate their behaviour.</p>

<p>For example, Trezor creates the first address at this location:
m/49'/0'/0'/0/0, and then the next address will be m/49'/0'/0'/0/1, and so on. So, it appears that it would be easy to just use an iterator over the last digit.</p>

<p>But, when you spend from m/49'/0'/0'/0/0, it moves the leftover to m/49'/0'/0'/1/0 . So, suddenly, I not only have to iterate over the last digit, I also have to iterate over the penultimate digit. I could have said "second last", but I said penultimate because it sounds more intelligent. </p>

<p><strong>Is there standard practice for traversing addresses?</strong> Something like, keep traversing over addresses until you hit an address with no transactions? Or possibly say three addresses in a row with no transactions? Or <strong>is this really the wild west and we just do whatever we feel like?</strong></p>

CC BY-SA 3.0
2018-01-08T00:24:07.580Z
I believe you might be looking for https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#account-discovery, but I'm not sure it fully answers your question
meshcollider
CC BY-SA 3.0
2018-01-08T00:49:01.057Z
I think answers my question as long as there are no gotchas. Are there corner cases that are not covered here? I actually found that Ledger is not 100% with Trezor and Vice Versa - i.e. they don't follow the same algorithm, so one must not be following the spec correctly.
Christian Findlay
CC BY-SA 3.0
2018-01-08T00:51:17.250Z
Would you mind clarifying what the difference between the two is?
meshcollider
CC BY-SA 3.0
2018-01-08T02:24:09.253Z
I don't know. It's just that when I restored my Trezor wallet on to the Ledger, the Ledger was missing some addresses, and therefore the balances didn't add up.
Christian Findlay
CC BY-SA 3.0
2018-01-08T02:27:45.810Z
@MeshCollider, but actually, this document is for BIP0044, and yet Trezor creates addresses at 49 which is different to what BIP0044 recommends. I'm so confused.
Christian Findlay
CC BY-SA 3.0
2018-01-08T02:29:40.180Z
@MeshCollider, BIP0044 matches the Trezor, as long as you apply the BIP0049 amendment. https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki
Christian Findlay
CC BY-SA 3.0
2018-01-08T02:30:00.977Z
@MeshCollider , if you want to write this up in more detail, I will mark your answer as the correct one.
Christian Findlay
<blockchain><address><bip32-hd-wallets><trezor>
How To Traverse Bitcoin Addresses in HD Wallet
Christian Findlay
# How To Traverse Bitcoin Addresses in HD Wallet

(Asked by: username_0 on 2018-01-08)

It appears that there are many way to traverse Bitcoin addresses. I am looking best practice, and I am also looking for the documented logic of how common wallets do it so I can replicate their behaviour.

For example, Trezor creates the first address at this location:
m/49'/0'/0'/0/0, and then the next address will be m/49'/0'/0'/0/1, and so on. So, it appears that it would be easy to just use an iterator over the last digit.

But, when you spend from m/49'/0'/0'/0/0, it moves the leftover to m/49'/0'/0'/1/0 . So, suddenly, I not only have to iterate over the last digit, I also have to iterate over the penultimate digit. I could have said "second last", but I said penultimate because it sounds more intelligent.

**Is there standard practice for traversing addresses?** Something like, keep traversing over addresses until you hit an address with no transactions? Or possibly say three addresses in a row with no transactions? Or **is this really the wild west and we just do whatever we feel like?**

**Tags:** blockchain, address, bip32-hd-wallets, trezor

> **Comments:**
> **username_1**: I believe you might be looking for https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#account-discovery, but I'm not sure it fully answers your question  
> **username_0**: I think answers my question as long as there are no gotchas. Are there corner cases that are not covered here? I actually found that Ledger is not 100% with Trezor and Vice Versa - i.e. they don't follow the same algorithm, so one must not be following the spec correctly.  
> **username_1**: Would you mind clarifying what the difference between the two is?  
> **username_0**: I don't know. It's just that when I restored my Trezor wallet on to the Ledger, the Ledger was missing some addresses, and therefore the balances didn't add up.  
> **username_0**: @MeshCollider, but actually, this document is for BIP0044, and yet Trezor creates addresses at 49 which is different to what BIP0044 recommends. I'm so confused.  
> **username_0**: @MeshCollider, BIP0044 matches the Trezor, as long as you apply the BIP0049 amendment. https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki  
> **username_0**: @MeshCollider , if you want to write this up in more detail, I will mark your answer as the correct one.  

---

## 1 answers

### Answer by username_2 on 2018-01-08. Score: 3 | Accepted answer

Most (but not all) wallets will follow what is specified in BIPs [32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki), [44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki), and [49](https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki).

BIP 32 defines what derivation paths are and what they mean. It is the standard for deriving all of the keys in a HD wallet.

BIPs 44 and 49 specify derivation paths that wallets should use. BIP 44 defines a standard derivation path format: `m / purpose' / coin_type' / account' / change / address_index`. It also defines the `purpose` for non-segwit Bitcoin keys.

When a wallet is deriving the keys, the path for external keys, i.e. those keys which you get by clicking "New Receive Address" (or similar) is `m/44'/0'/0'/0/i` and `i` is just incremented for new keys.

For internal keys, i.e. keys for change addresses, the derivation path will set the `change` field to `1`, so the path will be `m/44'/0'/0'/1/i` and `i` is incremented for each new change address that is needed.

Since that `change` field is essentially a boolean, there is no need to iterate through any indexes other than `0` and `1`.

BIP 49 specifies the `purpose` for keys used for P2SH nested segwit addresses. It just sets the `purpose` field to be 49, so the derivation paths will be `m/49'/0'/0'/k/i` where `k` is the `change` field and `i` is the `address_index`. The `change` and `address_index` fields remain the same as defined in BIP 44.

---

It is important to keep in mind that not all wallets follow BIPs 32, 44, and 49. For example, Armory uses its own HD wallet algorithm which predates BIP 32, although BIP 32 support for Armory is currently in the works. Other wallets such as Bitcoin Core and MultiBit HD do not follow BIP 44. Instead they use different derivation paths. For Bitcoin Core it's `m/k'/i'` where `k` is `change` (same definition as with BIP 44) and `i` is `address_index` (same definition as with BIP 44).

> **Comments:**
> **username_0**: This is a very clear explanation. Thankyou very much. It's enough for me to put the pieces together and also finish off my wallet.  

---

