<p>If you look closely, you'll notice that BIP 32 and BIP 44 actually have the same root key and it begins with <code>xprv</code>. Then BIP 49 and BIP 141 also have the same root key and it begins with <code>yprv</code>. BIP 84 has a root key that's different from the others that begins with <code>zprv</code>. Now if you were to take all of those root keys and Base 58 decode them, you'll find that they actually are identical except for the first 4 bytes and the last 4 bytes.</p>
<p>The last 4 bytes are because of the checksum used in Base 58 Check encoding.</p>
<p>But why are the first 4 bytes different? They are different because BIP 49 specifies for extended keys for nested segwit addresses should begin with the prefix <code>yprv</code> and <code>ypub</code>. Even though this is specific to BIP 49, this has been more generally applied to all extended keys for nested segwit addresses, thus you see it used for BIP 141. Then BIP 84 specifies that extended keys for native segwit addresses should begin with the prefix <code>zprv</code> and <code>zpub</code>.</p>
<p>These prefixes are what cause the different root keys as changing the prefix will cause the entire serialization to change as well.</p>
<p>By this logic, the <code>xprv</code> and <code>xpub</code> prefixes used previously then indicate that legacy addresses should be made. Hence BIP 44 shows <code>xprv</code>.</p>
<p>However BIP 32 is what specified the <code>xprv</code> and <code>xpub</code> prefix, and really this prefix is supposed to be independent of the derivation paths used and the addresses to be derived. BIP 32 is solely concerned with keys, not addresses. So <code>xprv</code> and <code>xpub</code> are used for general BIP 32 key derivation stuff too, which can make this confusing. But that's also why the BIP 32 tab shows <code>xprv</code>.</p>

CC BY-SA 4.0
2020-09-01T08:42:37.743Z
any reference on how the pub and prv strings are generated that you can kindly point me to?
3tbraden
CC BY-SA 4.0
2020-09-01T16:19:56.600Z
The serialization of extended keys is specified in BIP 32: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Serialization_format. For the different prefixes, there are just different version bytes and those can be found in their respective BIPs.
Ava Chow
CC BY-SA 4.0
2020-09-01T06:08:42.420Z
2020-09-01T06:08:42.420Z
Ava Chow
<p>When generating key on <a href="https://iancolemen.com/bip39/" rel="nofollow noreferrer">https://iancolemen.com/bip39/</a>, the BIP32 Root Key changes as I change the derivation path tab, e.g. BIP32, BIP44, BIP39 etc. Why is this the case? Isn't BIP32 Root Key the <code>m</code> at the beginning of the derivation path and the different standards are subsequent <code>purpose</code> that should not affect the root key?</p>
<p>Contrary to the above, when I generate addresses with the following code in go, the master key printed always matches the BIP32 Root Key on iancolemen.com. And changing the purpose does not affect the address generated in the end, it is always a BIP32(legacy) address, instead of a segwit which I would expect from BIP84.</p>
<pre><code>m, err := hdkeychain.NewMaster(seed, chainParams)
if err != nil {
    panic(err)
}
fmt.Println(&quot;bip32 root&quot;, m.String())

purpose, _ := m.Child(hdkeychain.HardenedKeyStart + 84)
coin, _ := purpose.Child(hdkeychain.HardenedKeyStart + 1)
account, _ := coin.Child(hdkeychain.HardenedKeyStart + 0)
receiving, _ := account.Child(0)
index, _ := receiving.Child(0)
fmt.Println(&quot;address&quot;, index.Address)
</code></pre>
<p>EDIT: The wrong address printed in go was a result from not properly encoding the addresses to bech32 and by default they are interpreted as legacy addresses. The keys themselves are alright.</p>

<address><bip32-hd-wallets><bech32-address><bip>
Why is BIP32 root key different for different standards(purposes)?
3tbraden
# Why is BIP32 root key different for different standards(purposes)?

(Asked by: username_0 on 2020-09-01)

When generating key on <https://iancolemen.com/bip39/>, the BIP32 Root Key changes as I change the derivation path tab, e.g. BIP32, BIP44, BIP39 etc. Why is this the case? Isn't BIP32 Root Key the `m` at the beginning of the derivation path and the different standards are subsequent `purpose` that should not affect the root key?

Contrary to the above, when I generate addresses with the following code in go, the master key printed always matches the BIP32 Root Key on iancolemen.com. And changing the purpose does not affect the address generated in the end, it is always a BIP32(legacy) address, instead of a segwit which I would expect from BIP84.

```
m, err := hdkeychain.NewMaster(seed, chainParams)
if err != nil {
    panic(err)
}
fmt.Println("bip32 root", m.String())

purpose, _ := m.Child(hdkeychain.HardenedKeyStart + 84)
coin, _ := purpose.Child(hdkeychain.HardenedKeyStart + 1)
account, _ := coin.Child(hdkeychain.HardenedKeyStart + 0)
receiving, _ := account.Child(0)
index, _ := receiving.Child(0)
fmt.Println("address", index.Address)

```

EDIT: The wrong address printed in go was a result from not properly encoding the addresses to bech32 and by default they are interpreted as legacy addresses. The keys themselves are alright.

**Tags:** address, bip32-hd-wallets, bech32-address, bip


---

## 1 answers

### Answer by username_1 on 2020-09-01. Score: 3 | Accepted answer

If you look closely, you'll notice that BIP 32 and BIP 44 actually have the same root key and it begins with `xprv`. Then BIP 49 and BIP 141 also have the same root key and it begins with `yprv`. BIP 84 has a root key that's different from the others that begins with `zprv`. Now if you were to take all of those root keys and Base 58 decode them, you'll find that they actually are identical except for the first 4 bytes and the last 4 bytes.

The last 4 bytes are because of the checksum used in Base 58 Check encoding.

But why are the first 4 bytes different? They are different because BIP 49 specifies for extended keys for nested segwit addresses should begin with the prefix `yprv` and `ypub`. Even though this is specific to BIP 49, this has been more generally applied to all extended keys for nested segwit addresses, thus you see it used for BIP 141. Then BIP 84 specifies that extended keys for native segwit addresses should begin with the prefix `zprv` and `zpub`.

These prefixes are what cause the different root keys as changing the prefix will cause the entire serialization to change as well.

By this logic, the `xprv` and `xpub` prefixes used previously then indicate that legacy addresses should be made. Hence BIP 44 shows `xprv`.

However BIP 32 is what specified the `xprv` and `xpub` prefix, and really this prefix is supposed to be independent of the derivation paths used and the addresses to be derived. BIP 32 is solely concerned with keys, not addresses. So `xprv` and `xpub` are used for general BIP 32 key derivation stuff too, which can make this confusing. But that's also why the BIP 32 tab shows `xprv`.

> **Comments:**
> **username_0**: any reference on how the pub and prv strings are generated that you can kindly point me to?  
> **username_1**: The serialization of extended keys is specified in BIP 32: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Serialization_format. For the different prefixes, there are just different version bytes and those can be found in their respective BIPs.  

---

