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.
TABLE OF CONTENTS
- Hierarchical deterministic wallets
- BIP32 - Hierarchical deterministic wallets
- BIP39 - Mnemonic code for generating deterministic keys
- BIP43 - Purpose field for deterministic wallets
- BIP44 - Multi-account hierarchy for deterministic wallets
- BIP49 - Derivation scheme for P2WPKH-nested-in-P2SH based accounts
- BIP84 - Derivation scheme for P2WPKH based accounts
- SLIP132 - Registered HD version bytes for BIP-0032
- SLIP32 - Extended serialization format for BIP-32 wallets
- SLIP44 - Registered coin types for BIP44
- SLIP48 - Deterministic key hierarchy for Graphene-based networks
- SLIP14 - Stress test deterministic wallet
- Extended applications of deterministic hierarchy
- SLIP10 - Universal private key derivation from master private key
- SLIP11 - Symmetric encryption of key-value pairs using deterministic hierarchy
- SLIP15 - Format for Bitcoin metadata and its encryption in HD wallets
- SLIP16 - Format for password storage and its encryption
- SLIP13 - Authentication using deterministic hierarchy
- SLIP17 - ECDH using deterministic hierarchy
- SLIP39 - Shamir's secret-sharing for mnemonic codes
- Transaction standards
- BIP16 - Pay to Script Hash
- BIP141 - Segregated Witness (Consensus layer)
- BIP173 - Base32 address format for native v0-16 witness outputs
- SLIP173 - Registered human-readable parts for BIP173
- BIP125 - Opt-in full replace-by-fee signalling
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):
m / index1 / index2 / ... / indexn
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:
m / 44' / 0' / 1' / 1 / 33
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:
- generating the recovery seed
- converting it into a binary master seed 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.
BIP43 - Purpose field for deterministic wallets
m / purpose'
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:
BIP44 - Multi-account hierarchy for deterministic wallets
m / 44' / coin_type' / account' / change / address
where for constants for coin_type index are defined by SLIP44.
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:
BIP49 - Derivation scheme for P2WPKH-nested-in-P2SH based accounts
m / 49' / coin_type' / account' / change / address
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:
BIP84 - Derivation scheme for P2WPKH based accounts
m / 84' / coin_type' / account' / change / address
- This BIP is currently not implemented in Trezor Suite, although there is support for P2WPKH in Trezor.
This SLIP acts as a registry for all coin HD version bytes.
SLIP132 - Registered HD version bytes for BIP-0032
- 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;
address = Base58Check ( <versionBytes> <transactionCommitment> )
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.
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.
SLIP32 - Extended serialization format for BIP-32 wallets
- This SLIP is not implemented yet and will replace SLIP132.
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.
SLIP44 - Registered coin types for BIP44
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:
SLIP48 - Deterministic key hierarchy for Graphene-based networks
m / 48' / network' / role' / account-index' / key-index'
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.
SLIP14 - Stress test deterministic wallet
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.
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.
SLIP11 - Symmetric encryption of key-value pairs using deterministic hierarchy
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.
SLIP15 - Format for Bitcoin metadata and its encryption in HD wallets
- It is used in Trezor Suite for labeling, each account has its own metadata file and encryption key.
m / 10015' / 0'
This SLIP describes simple encryption concept for a hardware device for secure storage of passwords. It is used in Trezor Password Manager.
SLIP16 - Format for password storage and its encryption
m / 10016' / 0
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.
SLIP13 - Authentication using deterministic hierarchy
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.
SLIP17 - ECDH using deterministic hierarchy
m / 17' / A' / B' / C' / D'
This SLIP describes a standard implementation of Shamir's secret-sharing for recovery seed. It is an multi-party alternative to BIP39.
SLIP39 - Shamir's secret-sharing for mnemonic codes
SLIP39 has been first implemented in the firmware v.2.1.3 for Trezor Model T. See Shamir backup for more information.
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.
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.
BIP141 - Segregated Witness (Consensus layer)
This BIP proposes a new format for native SegWit addresses, called Bech32.
BIP173 - Base32 address format for native v0-16 witness outputs
This SLIP registers prefixes of native SegWit addresses in Bech32 format for non-bitcoin cryptocurrencies omitted by BIP173.
SLIP173 - Registered human-readable parts for BIP173
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.
BIP125 - Opt-in full replace-by-fee signalling