Cryptocurrency standards

From Trezor Wiki
Jump to: navigation, search

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

Hierarchical deterministic wallets[edit]

BIP32 - Hierarchical deterministic wallets [edit]


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 

See also: BIP32 source, Hardened and non-hardened derivation, SLIP32

BIP39 - Mnemonic code for generating deterministic keys [edit]

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

BIP43 - Purpose field for deterministic wallets [edit]

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

BIP44 - Multi-account hierarchy for deterministic wallets [edit]

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.

See also: BIP44 source, legacy account

BIP49 - Derivation scheme for P2WPKH-nested-in-P2SH based accounts [edit]

This BIP defines an implementation of a HD wallet for SegWit P2WPKH-in-P2SH addresses (e.g. 3-addresses in Bitcoin). Except for the address type, it is similar to BIP44:

m / 49' / coin_type' / account' / change / address

See also: BIP49 source

BIP84 - Derivation scheme for P2WPKH based accounts [edit]

This BIP defines an implementation of a HD wallet for native SegWit P2WPKH addresses (e.g. bc1-addresses in Bitcoin). Except for the address type, it is similar to BIP44:

m / 84' / coin_type' / account' / change / address

This BIP is currently not implemented in Trezor Wallet, although there is support for P2WPKH in Trezor.

See also: BIP84 source

SLIP132 - Registered HD version bytes for BIP-0032 [edit]

This SLIP acts as a registry for all coin HD version bytes.

See also: SLIP132 source

SLIP32 - Extended serialization format for BIP-32 wallets [edit]

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

SLIP44 - Registered coin types for BIP44 [edit]

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

SLIP48 - Deterministic key hierarchy for Graphene-based networks [edit]

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

SLIP14 - Stress test deterministic wallet [edit]

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[edit]

SLIP10 - Universal private key derivation from master private key [edit]

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

SLIP11 - Symmetric encryption of key-value pairs using deterministic hierarchy [edit]

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

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.

m / 10015' / 0'

See also: SLIP15 source

SLIP16 - Format for password storage and its encryption [edit]

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

SLIP13 - Authentication using deterministic hierarchy [edit]

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'

See also: SLIP13 source, Sign in with Trezor

SLIP17 - ECDH using deterministic hierarchy [edit]

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

SLIP39 - Shamir's secret-sharing for mnemonic codes [edit]

This SLIP describes a standard implementation of Shamir's secret-sharing for recovery seed. It is an multi-party alternative to BIP39.

SLIP39 has been first implemented in the firmware v.2.1.3 for Trezor Model T. See Shamir backup for more information.

See also: SLIP39 source

Transactions standards[edit]

BIP16 - Pay to Script Hash [edit]

This BIP describes P2SH transaction type (e.g. 3-addresses in Bitcoin). Its current main usage are MultiSig and SegWit transactions.

See also: BIP16 source

BIP141 - Segregated Witness (Consensus layer) [edit]

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.

BIP173 - Base32 address format for native v0-16 witness outputs [edit]

This BIP proposes a new format for native SegWit addresses, called Bech32. It is currently not supported in Trezor Wallet, although it is supported in Trezor.

See also: BIP173 source

SLIP173 - Registered human-readable parts for BIP173 [edit]

This SLIP registers prefixes of native SegWit addresses in Bech32 format for non-bitcoin cryptocurrencies omitted by BIP173.

See also: SLIP173 source

BIP125 - Opt-in full replace-by-fee signalling [edit]

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

Like Trezor? Get one here!