BIP-49 derivation

BIP-49 reserves the first hardened level of the key tree, 49', for accounts whose addresses are P2WPKH wrapped inside P2SH. It was assigned on 19 May 2016 and later gained its own extended key version bytes, 0x049d7cb2 for ypub and 0x049d7878 for yprv. If your wallet exports an account key beginning with ypub, that is the branch a restore has to look down.

How it works

BIP-49 settles two questions: which branch of a BIP-32 tree holds wrapped SegWit keys, and how an address is built from a key on that branch.

The branch borrows the five level template BIP-44 already used, m / purpose' / coin_type' / account' / change / address_index, and changes exactly one number. Purpose becomes 49' instead of 44'. Coin type, account, chain and index keep the meanings BIP-44 gave them.

The address half is mechanical: hash the compressed public key, wrap the 20 byte result in a 22 byte redeem script, then hash that script to get what the output commits to. The spec writes the two pieces as scriptSig: 0x160014{20-byte-key-hash} and scriptPubKey: 0xA914{20-byte-script-hash}87.

The interesting part is the option the author rejected. Weigl lists two approaches: keep the account you already have and hang wrapped SegWit addresses off the same public keys, or mint dedicated accounts under a new purpose. The first is friendlier until something goes wrong, and then, in the spec's words, the account "might show up but also it might miss some UTXOs". BIP-49 chose dedicated accounts precisely because that option "fails in a more visible way". An empty screen is a better error message than a plausible wrong number.

Serialization got the same treatment, eventually: extended public keys on this branch use version bytes 0x049d7cb2, base58 encoding to the prefix ypub, with 0x049d7878 for yprv and upub and uprv on testnet.

Where you see it

BIP-49 shows up as an extended key beginning with ypub rather than xpub, and as the wrapped SegWit account a wallet lists beside the native one. Mycelium, which we rate 3.7, carries native and wrapped SegWit accounts in one app, the two schemes SLIP-0132 registers under zpub and ypub.

The ypub prefix was a retrofit, and that history still shows. BIP-43, which invented the purpose level in 2014, told implementers to keep 0x0488B21E and the xpub prefix for every purpose. BIP-49 shipped that way at first, and SLIP-0132, created on 8 February 2018 to register version bytes properly, describes the result bluntly: the unchanged prefix led to "unsustainable user confusion", because either the user had to remember which branch an xpub came from or the receiving tool had to scan both address spaces. A prefix is a hint, not a guarantee. If you paste an extended key into a block explorer and it derives addresses starting with 1 while your wallet shows addresses starting with 3, you are holding a BIP-49 key wearing the older prefix, and the tool needs to be told the path by hand.

The spec ships a testnet vector worth checking a tool against: the phrase abandon repeated eleven times followed by about, account root m/49'/1'/0', first receiving address 2Mww8dCYPUpKHofjgcXcBCEGmniw9CoaiD2.

BIP-49 derivation vs nested SegWit

BIP-49 derivation is a rule about keys, and nested SegWit is a pattern the chain sees; the two usually travel together, but neither implies the other. An output is nested SegWit because of the script it commits to, and nothing in it records which path produced the key. A wallet can build one from an imported private key, or from the approach BIP-49 rejected, which derived a second P2SH address from public keys already sitting in a BIP-44 account. Knowing your coins are on 3 addresses therefore does not tell you where to restore, which is why the account path belongs in your notes beside the seed backup.