Understanding Crypto Addresses and Derivation Paths in Ledger Live

Key Takeaways:

– Seed, addresses and keys – BIP32, BIP39 and BIP44 – UTXO Model vs Account Model – LedgerJS

HD Wallets – Using a single seed to generate a tree of keys

An address of a crypto asset maps to a script, which specifies a set of spending conditions. In order to spend crypto from an account, we need to broadcast a transaction that satisfies those spending conditions. This process requires the signature from the Ledger Nano.

The HD Wallets (Hierarchical Deterministic wallet) proposal appeared in the bitcoin community around 2013, as BIP32 (Bitcoin Improvement Protocol). It suggests an algorithm to create a master pair of private/public keys, and then use this private key to generate an unlimited number of “children’s addresses”. Each child is also a pair of private/public keys able to generate the next level grandchildren in the same way as its parent.

Tree of keys

In the above tree, the “children’s addresses” can be calculated from their direct ancestor but not vice versa which is guaranteed by cryptography. That’s how the HD Wallets proposal greatly facilitates key management, since a wallet user has only one seed to maintain.

BIP39 & BIP44 – Mnemonic and derivation path

Besides BIP32, Ledger Live complies with BIP39 and BIP44.

BIP39

BIP39 is a proposal that provides an algorithm to represent a 128/256 bits master private key + a checksum with a 12/24 word list. This word list is called mnemonic or seed. A Ledger user is asked to import or generate this mnemonic before using its Ledger Nano.

Seed generation on a Ledger Nano

All your Ledger addresses and keys are generated with this seed and organized in a “tree of keys” structure. BIP44 proposal defines a standard for this tree of keys/addresses management structure. This standard is used by Ledger Live.

A derivation path looks like the following:

m / purpose' / coin_type' / account' / change / address_index

It is a special case of a HD wallet tree with 5 levels in BIP32 path. A derivation path like this one determines the location of a node in the tree of keys.

The apostrophe in the path indicates that BIP32 hardened derivation is used. For more details about derivation and hardened derivation algorithm, please refer to BIP32.

BIP44

BIP44 proposal originates from the Bitcoin community but is also used in many other blockchain ecosystems.

Each level of this derivation path has a special meaning:

m / purpose' / coin_type' / account' / change / address_index

• purpose: legacy bitcoin accounts and other blockchain ecosystems that comply with BIP44 (44), segwit (49), Native segwit (84), Bitcoin taproot (86)
• coin_type: Refer to SLIP44 – Registered coin types for BIP44. Every crypto currency has its own value. This field allows accounts from different blockchains to use completely different and independent trees of keys. It guarantees isolation and avoids key reuse, which would be a privacy leak.
• account: the account index of the same crypto currency in Ledger Live.
  • 1st bitcoin account: account = 0
  • 2nd bitcoin account: account = 1
  • 3rd bitcoin account: account = 2
  • …
• change: 0 for receiving address and 1 for change address
• address_index: an incremental address index for the account. It is used to number different addresses in an account of UTXO model crypto assets. More details in the next section.

In Ledger live, in the Account page, we can see this kind of derivation path by clicking Edit account -> ADVANCED -> freshAddressPath

Bitcoin – Derivation path in Ledger Live

This freshAddressPath is a BIP44 path. Since a HD wallet complies with BIP32 in our Ledger ecosystem, a seed along with a BIP44 path can determine a public key. A crypto asset address is just a differently formatted public key. This BIP44 fresh address path corresponds to the address in the receive flow of the same account in Ledger Live:

Receive flow in Ledger Live

UTXO model vs. Account model

UTXO model

A set of crypto currencies supported by Ledger live (bitcoin, bitcoinCash, bitcoinGold, dash, digibyte, dogecoin, komodo, litecoin, peercoin, pivx, qtum, vertcoin, viacoin, zcash, zencash, decred) uses UTXO (Unspent Transaction Output) model.

An UTXO is a discrete piece of crypto assets. It represents some amount of digital currency that is associated with an address. In order to protect privacy, when a bitcoin account receives a transaction, it always gives a fresh address to the sender. A fresh address is a new empty address without any transaction history, which makes it impossible to track all the historical transactions of an account using one given transaction or address (found on a crypto explorer).

Change addresses have the similar fresh address mechanism: as it is impossible to spend portions of a UTXO, the wallet of the sender selects a set of UTXOs that has at least as much total value as we want to send (plus the required network fees), and sends the excess money back to the sender as a new UTXO. This UTXO is sent back to the sender at a new change address every time.

Change address in a Bitcoin transaction

E.g. With the first bitcoin taproot account in Ledger live, user receives:

• 1st transaction with the fresh address of derivation path m/86’/0’/0’/0/0.
• 2nd transaction with the fresh address of derivation path m/86’/0’/0’/0/1.
• 3rd transaction with the fresh address of derivation path m/86’/0’/0’/0/2.

When the account owner sends bitcoin from this account, it receives change at the address of derivation path m/86’/0’/0’/1/0 and then m/86’/0’/0’/1/1, and then m/86’/0’/0’/1/2, etc…

Account model

Most other crypto currencies supported by Ledger Live (ethereum, solana, cosmos, polkadot, tron…) use the Account model.

Unlike the UTXO model, the crypto assets using the Account model have only one address for each account. Everyone can track full historical transactions of an account by using the address in a blockchain explorer. So, to protect the privacy, users should be extra careful to segregate their public accounts from private accounts that are not linked to their identity. There is no “change address” for this kind of crypto assets.

So, in the BIP44 derivation path, the last two level are usually equal to “0”:

• m / purpose' / coin_type' / account' / 0 / 0

The derivation path of an Ethereum account in Ledger live looks like:

Ethereum – Derivation Path in Ledger Live transaction

LedgerJS – Get address from Ledger device

LedgerJS is a set of JavaScript libraries that provides high-level APIs to communicate with Ledger devices. It is used by Ledger live and other external applications that want to connect to Ledger devices. With the help of these libs, developers can communicate with Ledger devices without handling low-level communication protocol.

One of the APIs provided by LedgerJS is getAddress.

For Account model crypto assets such as Ethereum, how easy is it to get the address from a Ledger device with the derivation path 44'/60'/0'/0/0 ? Here is the Javascript code:

import Eth from "@ledgerhq/hw-app-eth";
import eip55 from "eip55";
const eth = new Eth(transport);
const r = await eth.getAddress("44'/60'/0'/0/0");
const address = eip55.encode(r.address);

For UTXO model crypto assets such as bitcoin, it is a little bit more complicated:

import Btc from "@ledgerhq/hw-app-btc";
const btc = new Btc(transport);
const xpub = await btc.getWalletXpub({ path: "84'/0'/0'", xpubVersion });

We introduce two notions here, xpubVersion and xpub:

• xpub is short for “Extended public key” and it is a kind of conversion from the public key of a node from the derivation tree. It gives access to the public key and addresses of its children nodes in the BIP32 tree. In the above snippet of code, 84’/0’/0’ are the first three levels of the BIP44 derivation path (purpose=84, coin_type=0, account=0). The xpub corresponds to this node. So we fetch the xpub from the LedgerJS API.
• xpubVersion is a BIP32 parameter of 4 bytes, it varies according to different crypto assets and networks.

E.g. For bitcoin mainnet, xpubVersion = 0x0488b21e.
For bitcoin testnet, xpubVersion = 0x043587cf.
For dogecoin, xpubVersion = 0x02facafd.

In Leger Live, every account has a unique xpub that can be found in the Edit account page.

xpub in Ledger Live

Ledger Live generates all addresses of an account from its xpub.

customGetAddress(
   derivationMode: string,
   xpub: string,
   account: number,
   index: number
 ): Promise<string>;

For UTXO model crypto assets, such as Bitcoin, every crypto asset implements this method interface.

• The derivationMode parameter is one of the four supported values: “legacy”, “segwit”, “native segwit” or “taproot”.
• The account parameter corresponds to the 4th derivation path level from BIP44.
• The index parameter corresponds to the 5th level.

E.g. for the BIP44 path 84'/0'/1'/3/9, account =3 and index = 9 It returns as a string the crypto address used by Ledger live and the blockchain.

To protect their privacy, Ledger always asks users not to leak the xpub. As with the xpub of an account, anyone can track all past and future transactions of the account.

Conclusion

Ledger is not only a software editor but also an ecosystem builder. As developers at Ledger, we always improve Ledger Live to adapt to the newest standards from blockchain developer communities. Moreover, we provide libraries such as LedgerJS, allowing developers all over the world to integrate Ledger products to their website, mobile app or Dapp in an easy way. More documentation can be found in https://developers.ledger.com/

Welcome to our ecosystem!

Reference

• BIP32
• BIP39
• BIP44