Search

Cryptocurrency standards

This is an overview of cryptocurrency standardsBIPs 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.

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):

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.

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.

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:

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 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:

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.

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.

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.

SLIP15 - Format for Bitcoin metadata and its encryption in HD wallets [edit]

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.

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.

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.

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.