arno/trezor-firmware
1
0
Fork 0
mirror of https://github.com/trezor/trezor-firmware.git synced 2024-12-23 14:58:09 +00:00
Code Issues Releases Wiki Activity
ad38d8e324
trezor-firmware/docs/misc/coins-bip44-paths.md
matejcik 395324a8ad chore(docs): remove Lisk
2021-08-19 10:25:41 +02:00

4.5 KiB
Raw Blame History

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.

Keys are derived according to SLIP-10, which is a superset of the BIP-32 derivation algorithm, extended to work on other curves.

List of used derivation paths

coin curve path public node note
Bitcoin secp256k1 44'/c'/a'/y/i yes 1
Ethereum secp256k1 44'/c'/0'/0/a yes 2
Ripple secp256k1 44'/144'/a'/0/0 3
EOS secp256k1 44'/194'/a'/0/0 3
Binance secp256k1 44'/714'/a'/0/0 3
Tron secp256k1 TODO TODO
Ontology nist256p1 TODO TODO
Cardano ed25519 44'/1815'/a'/y/i yes 4
Stellar ed25519 44'/148'/a'
NEM ed25519 44'/43'/a' 5
Monero ed25519 44'/128'/a'
Tezos ed25519 44'/1729'/a' 6

c stands for the SLIP-44 id of the currency, when multiple currencies are handled by the same code. a is an account number, y is change address indicator (must be 0 or 1), and i is address index.

Paths that do not conform to this table are allowed, but user needs to confirm a warning on Trezor.

Public nodes

Some currencies allow exporting a public node, which lets the client derive all non-hardened paths below it. In that case, the conforming path is equal to the hardened prefix.

I.e., for Bitcoin's path 44'/c'/a'/y/i, the allowed public node path is 44'/c'/a'.

Trezor does 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 legacy multisig SPENDMULTISIG
    49 p2sh segwit SPENDP2SHWITNESS
    84 native segwit SPENDWITNESS

    Other p are disallowed.

  2. We believe this should be 44'/c'/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.

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

  4. Cardano has a custom derivation algorithm that allows non-hardened derivation on ed25519.

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

  2. 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 UTXO-based currencies, account number a needs to be in the interval [0, 20] and address index i in the interval [0, 1 000 000].

For account-based currencies (i.e., those that do not use address indexes), account number a needs to be in the interval [0, 1 000 000]