1
0
mirror of https://github.com/trezor/trezor-firmware.git synced 2024-12-16 19:38:09 +00:00
trezor-firmware/docs/coins/README.md
Tomas Susanka 31f987e988 coins: validate derivation paths
Based on SLIP-44 ids and other checks. See docs/coins/README for info.
2018-11-12 12:10:32 +01:00

4.2 KiB

BIP-44 derivation paths

Each coin uses BIP-44 derivation path scheme. If the coin is UTXO-based the path should have all five parts, precisely as defined in BIP-32. If it is account-based we follow Stellar's SEP-0005 - paths have only three parts 44'/c'/a'. Unfortunately, lot of exceptions occur due to compatibility reasons.

List of used derivation paths

coin curve getPublicKey getAddress sign tx derivation note
Bitcoin secp256k 44'/c'/a' 44'/c'/a'/y/i 44'/c'/a'/y/i BIP-32 1
Ethereum secp256k 44'/60'/0' 44'/60'/0'/0/i 44'/60'/0'/0/i BIP-32 2
Ripple secp256k - 44'/144'/a'/0/0 44'/144'/a'/0/0 BIP-32 3
Cardano ed25519 44'/1815'/a' 44'/1815'/a'/{0,1}/i 44'/1815'/a'/{0,1}/i Cardano's own4
Stellar ed25519 - 44'/148'/a' 44'/148'/a' SLIP-0010
Lisk ed25519 44'/134'/a' 44'/134'/a' 44'/134'/a' SLIP-0010
NEM ed25519 - 44'/43'/a' 44'/43'/a' SLIP-0010 5
Monero ed25519 44'/128'/a'6 44'/128'/a' 44'/128'/a' SLIP-0010
Tezos ed255197 44'/1729'/a' 44'/1729'/a' 44'/1729'/a' SLIP-0010

Paths that do not conform to this table are allowed, but user needs to confirm a warning on Trezor. For getPublicKey we do not check if the path is followed by other non-hardened items (anyone can derive those anyway). This is beneficial for Ethereum and its MEW compatibility, which sends 44'/60'/0'/0 for getPublicKey.

Notes

  1. For Bitcoin and its derivatives it is a little bit more complicated. p is decided based on the following table:
    p type input script type
    44 legacy SPENDADDRESS
    48 multisig SPENDMULTISIG
    49 p2sh segwit SPENDP2SHWITNESS
    84 native segwit SPENDWITNESS

Other p are disallowed. c has to be equal to the coin's slip44 id as for every coin. y needs to be 0 or 1.

  1. We believe this should be 44'/60'/a', because Ethereum is account-based, rather than UTXO-based. Unfortunately, lot of Ethereum tools (MEW, Metamask) do not use such scheme and set a = 0 and then iterate the address index i. Therefore for compatibility reasons we use the same scheme: 44'/60'/0'/0/i and only the i is being iterated.

  2. Similar to Ethereum this should be 44'/144'/a'. But for compatibility with other HW vendors we use 44'/144'/a'/0/0.

  3. Which allows non-hardened derivation on ed25519.

  4. NEM's path should be 44'/60'/a' as per SEP-0005, but we allow 44'/60'/a'/0'/0' as well for compatibility reasons with NanoWallet.

  5. Actually it is GetWatchKey for Monero.

  6. Tezos supports multiple curves, but Trezor currently supports ed25519 only.

Sign message paths are validated in the same way as the sign tx paths are.

Allowed values

For GetPublicKey a needs in the interval of [0, 20]. For GetAddress and signing the longer five-items paths need to have a also in range of [0, 20] and i in [0, 1000000]. If only three-items paths are used (Stellar and Lisk for example), a is allowed to be in [0, 1000000] (because there is no address index i).