What are BIPs & SLIPs?

Bitcoin Improvement Proposals (BIPs) are open-design documents for introducing new standards and features to Bitcoin, such as new transaction types like SegWit or their properties like replace-by-fee (RBF).

SatoshiLabs Improvement Proposals (SLIPs) are documents similar to BIPs, which are not suitable for BIP submission. SLIPs are curated by SatoshiLabs and they often extend a BIP repository, e.g. by a detailed description of wallet structures.
 

Trezor devices and Trezor Suite implement many of these standards, as described below.
 

Hierarchical deterministic wallets

BIP32 - Hierarchical 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):
     
Hardened and non-hardened derivation

There are two possible types of BIP32 derivation, hardened or non-hardened. In standard BIP32 path notation, hardened derivation at a particular level is indicated by an apostrophe. For example, the following example of hardened derivation is used for the first three levels, while for the last two levels non-hardened derivation is used:
 
With non-hardened keys, you can prove a child public key is linked to a parent public key using just the public keys. You can also derive public child keys from a public parent key, which enables watch-only wallets. With hardened child keys, you cannot prove that a child public key is linked to a parent public key.

For security reasons, using hardened keys is safer, but there are use cases for using non-hardened keys. A parent extended public key together with a non-hardened child private key can expose the parent private key. This means that extended public keys must be treated more carefully than regular public keys. It is also the reason for the existence of hardened keys and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private keys never risks compromising the master or other accounts.
 

BIP39 - Mnemonic code for generating deterministic keys

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 
2. converting it into a binary master seed including an optional application of a passphrase during the conversion.

 

BIP43 - Purpose field for deterministic wallets

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.
   

BIP44 - Multi-account hierarchy for deterministic wallets

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.
 

BIP49 - Derivation scheme for P2WPKH-nested-in-P2SH based accounts

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
 

BIP84 - Derivation scheme for P2WPKH based accounts

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:
   

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

 

SLIP132 - Registered HD version bytes for BIP-0032

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

• In Bitcoin-like cryptocurrencies, version bytes is a piece of data that is responsible for making different kinds of addresses and account public keys distinguishable in order to prevent potential errors leading to confusion and loss of funds.

Relation of version bytes and address: technically, an address is base58check-encoded form of transaction commitment prefixed by version bytes;
 
where transaction commitment is either public key hash for P2PKH, or script hash for P2SH.

Unlike transaction commitments, version bytes and addresses are not included in blockchain. Rather, they are implemented on cryptocurrency software level by wallets and services. Sometime this implementation may change which leads to confusion among users and to transactional problems with services that are slow to adopt the change. This was the case with Litecoin's P2SH where address prefix changed from "3" to "M" to prevent confusion with similar addresses in Bitcoin. In such cases, custom tools are needed to convert an address to different format.
 

See also:  SLIP132 source

SLIP32 - Extended serialization format for BIP-32 wallets

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

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

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

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

SLIP10 - Universal private key derivation from master private key

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

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

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 Suite for labeling, 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

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

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

SLIP17 - ECDH using deterministic hierarchy

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

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

Transaction standards

BIP16 - Pay to Script Hash

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)

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

This BIP proposes a new format for native SegWit addresses, called Bech32.
 

See also:  BIP173 source

SLIP173 - Registered human-readable parts for BIP173

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

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.