This is an overview of cryptocurrency standards BIPs and SLIPs that are relevant to the Trezor device or Trezor Wallet, meaning they are either already supported or their support is planned. The standards are organized into groups based on their common topic below.
See also: Cryptography standards
- 1 Hierachical deterministic wallets
- 1.1 BIP32 - Hierarchical deterministic wallets
- 1.2 BIP39 - Mnemonic code for generating deterministic keys
- 1.3 BIP43 - Purpose field for deterministic wallets
- 1.4 BIP44 - Multi-account hierarchy for deterministic wallets
- 1.5 BIP49 - Derivation scheme for P2WPKH-nested-in-P2SH based accounts
- 1.6 BIP84 - Derivation scheme for P2WPKH based accounts
- 1.7 SLIP132 - Registered HD version bytes for BIP-0032
- 1.8 SLIP32 - Extended serialization format for BIP-32 wallets
- 1.9 SLIP44 - Registered coin types for BIP44
- 1.10 SLIP48 - Deterministic key hierarchy for Graphene-based networks
- 1.11 SLIP14 - Stress test deterministic wallet
- 2 Extended applications of deterministic hierarchy
- 2.1 SLIP10 - Universal private key derivation from master private key
- 2.2 SLIP11 - Symmetric encryption of key-value pairs using deterministic hierarchy
- 2.3 SLIP15 - Format for Bitcoin metadata and its encryption in HD wallets
- 2.4 SLIP16 - Format for password storage and its encryption
- 2.5 SLIP13 - Authentication using deterministic hierarchy
- 2.6 SLIP17 - ECDH using deterministic hierarchy
- 2.7 SLIP39 - Shamir's secret-sharing for mnemonic codes
- 3 Transactions standards
Hierachical deterministic wallets
This BIP describes a general structure of hierarchical deterministic wallet (HD wallet). In particular, it defines how to derive private and public keys of a wallet from a binary master seed (m) and an ordered set of indices (so called BIP32 path):
m / index1 / index2 / ... / indexn
This BIP describes the implementation of a recovery seed and its relation to BIP32 binary master seed. It consists of two parts: 1) generating the recovery seed and 2) converting it into a binary master seed
m including an optional application of a passphrase during the conversion.
See also: BIP39 source
BIP32 alone offers too many degrees of freedom how a wallet can be implemented. This is why BIP43 introduces a rule that the first derivation index called
purpose should correspond to a BIP that describes wallet structure on subsequent levels. Thus, if, for example, a wallet compliant with BIP39 uses
m/44'/... derivation path, it suggests that its structure is described by BIP44.
m / purpose'
See also: BIP43 source
This BIP defines an implementation of a HD wallet based on BIP32 and BIP43. In particular, it describes multi-coin wallet structure for P2PKH addresses (e.g. 1-addresses in Bitcoin) and algorithm for wallet discovery:
m / 44' / coin_type' / account' / change / address
where for constants for
coin_type index are defined by SLIP44.
m / 49' / coin_type' / account' / change / address
See also: BIP49 source
m / 84' / coin_type' / account' / change / address
See also: BIP84 source
This SLIP acts as a registry for all coin HD version bytes.
See also: SLIP132 source
This SLIP defined extended version of the serialization format defined in BIP32. This version aims to overcome some limitations of the original proposal. First modification is including full BIP32 path of the exported node and second modification is removal of fingerprint field.
This SLIP is not implemented yet and will replace SLIP132.
See also: SLIP32 source
This SLIP defines cryptocurrency constants that are used for
coin_type index in BIP44 and other similar BIPs. For example Bitcoin = 0, all testnets = 1 and Litecoin = 2.
See also: SLIP44 source
This SLIP defines an implementation of a HD wallet for Graphene-based networks (such as BitShares, Steem, Peerplays, MUSE). It is an alternative to BIP44-like wallet structure that is not suitable for the purposes of these cryptocurrencies:
m / 48' / network' / role' / account-index' / key-index'
See also: SLIP48 source
This SLIP is informational. It describes a stress test deterministic wallet, which can be used to test various cornercases that such wallet can encounter. Development of Trezor deterministic wallet showed there are quite a lot of different types of transactions in the network. In order to simplify testing of transaction history, Trezor developers came up with the idea to create a special XPUBs that will contain these various types of transactions.
See also: SLIP14 source
Extended applications of deterministic hierarchy
This SLIP describes how to derive private and public key pairs for curve types different from secp256k1.
Trezor generates all keys from a 12 to 24 word mnemonic sequence and optionally a passphrase. The BIP39 standard describes the procedure to compute a 512-bit seed from this passphrase. From this seed, Trezor can create several master keys, one for each curve. It uses a process similar and compatible to BIP32. For other curves, it uses a different salt than BIP32. This avoids using the same private key for different elliptic curves with different orders.
See also: SLIP10 source
This SLIP describes symmetric encryption of key-value pairs using deterministic hierarchy. The key doesn't exit the hardware wallet and the user might be forced to confirm the encryption/decryption on the display. It is mainly used in SLIP15 and SLIP16.
See also: SLIP11 source
This SLIP describes a format to save Bitcoin transaction metadata (labels to accounts, transactions) in a secure way, with regard to HD wallet, especially (but not limited to) hardware HD wallets. It is used in Trezor wallet for labelling, each account has its own metadata file and encryption key.
m / 10015' / 0'
See also: SLIP15 source
This SLIP describes simple encryption concept for a hardware device for secure storage of passwords. It is used in Trezor Password Manager
m / 10016' / 0
See also: SLIP16 source
This SLIP describes authentication using deterministic hierarchy, a method that is used for authenticating to various services such as websites or remote shells using a deterministic hierarchy. It is used for signing in various services using Trezor.
m / 13' / A' / B' / C' / D'
This SLIP describes a method for implementing the Elliptic Curve Diffie-Hellman algorithm, using a deterministic hierarchy. Using deterministic hierarchy for encryption and decryption is ideal because the same concepts of easy backup that relate to backing up deterministic wallets can be applied to backing up private keys.
m / 17' / A' / B' / C' / D'
See also: SLIP17 source
This SLIP is not implemented in Trezor yet.
See also: SLIP39 source
See also: BIP16 source
This BIP enabled SegWit as a soft-fork in Bitcoin. It is also prerequisite for Lightning network as it solves malleability issue of pre-segwit transaction types. In particular, BIP141 defines the following new transaction type: P2WPKH, P2WPKH-in-P2SH, P2WSH, P2WSH-in-P2SH, where only the first two types are currently supported in Trezor.
See also: BIP141 source.
See also: BIP173 source
See also: SLIP173 source
This BIP describes Replace-by-fee (RBF) signalling policy. It allows spenders to add a signal to a transaction indicating that they want to be able to replace that transaction until it becomes confirmed.
See also: BIP125 source