• Ethereumbook – Wallets
  • Ethereumbook by EthereumBook
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: XatMassacrE
  • Proofread by: Leviding

The term “wallet” doesn’t mean what it meant in Ethereum.

At a macro level, wallet is basically an application that provides users with a user interface. It handles users’ money, manages keys and addresses, tracks account balances and creates transactions and signatures. In addition, some Ethereum wallets can also interact with smart contracts, such as tokens.

More accurately, from a programmer’s perspective, the term “wallet” refers to a system that stores and manages keys and addresses. Each “wallet” has a key management component. For some wallets, that’s all there is to it. Most of the other wallets are “browsers,” essentially interfaces to decentralized applications based on Ethereum. So there is no clear line between these various wallets.

Let’s first take a look at the functions of the wallet in terms of key management and private key containers.

An overview of wallet technology

In this section we’ll summarize the various technologies needed to build a user friendly, secure, and flexible Ethereum wallet.

One of the most common misconceptions about Ethereum is that most people think ethereum wallets contain Ethereum and other tokens. In fact, wallets contain only keys. Ethereum and other tokens are recorded in Ethereum’s blockchain. Users control tokens by signing their wallets with keys in their wallets. So in a sense, the Ethereum wallet is a keychain.

prompt

Ethereum wallets contain only keys, not Ethereum and tokens. Every user’s wallet contains a key. A wallet is a chain of keys containing public and private key pairs. Users sign transactions using keys to prove that ethereum belongs to them. The real Ethereum is stored on a blockchain.

There are two main types of wallets, and the difference is whether the keys they contain are related to each other.

The first type is called a nondeterministic wallet, in which each key is independently generated from a random number. Keys are not related to each other. This wallet is also called a JBOK wallet (from “Just a Bunch Of Keys”).

The second type of wallet is called a deterministic wallet, in which all keys are derived from a single master key called a seed. All the keys in the wallet are related to each other, and anyone with the original seed can regenerate the keys again. This deterministic wallet uses many different key derivation methods. One of the most commonly used is a tree-like structure called hierarchical deterministic or HD wallet.

The hierarchical deterministic wallet is initialized with a seed. For ease of use, the seeds are encoded into English words (or words from other languages) called mnemonics.

The following sections introduce these techniques at a more advanced level.

Nondeterministic (random) wallets

In the first Ethereum wallet (released when Ethereum was pre-sold), the wallet file stored a separate, randomly generated private key. However, this wallet has since been replaced by a deterministic wallet, which cannot manage, back up, or import private keys. But the downside of random keys is that if you generate a lot of them you have to copy them all. Every key should be backed up, otherwise the assets corresponding to those keys will be lost if the wallet is lost. Further, the privacy of Ethereum addresses is greatly reduced by the multiple transactions associated with each other and the repeated use of addresses. A non-deterministic wallet of type -0 is not a good choice, especially if you have to manage multiple keys and back them up frequently to avoid address duplication.

Many Ethereum clients (including Go-Ethereum and GEth) use a keystring file, which is a JSON-encoded file that also contains a separate (randomly generated) private key that is encrypted with a password for security. The JSON file looks like this:

{
    "address": "001d3f1ef827552ae1114027bd3ecf1f086ba0f9",
    "crypto": {
        "cipher": "aes-128-ctr",
        "ciphertext": "233a9f4d236ed0c13394b504b6da5df02587c8bf1ad8946f6f2b58f055507ece",
        "cipherparams": {
            "iv": "d10c6ec5bae81b6cb9144de81037fa15"
        },
        "kdf": "scrypt",
        "kdfparams": {
            "dklen": 32,
            "n": 262144,
            "p": 1,
            "r": 8,
            "salt": "99d37a47c7c9429c66976f643f386a61b78b97f3246adca89abe4245d2788407"
        },
        "mac": "594c8df1c8ee0ded8255a50caf07e8c12061fd859f4b7c76ab704b17c957e842"
    },
    "id": "4fcb2ba4-ccdb-424f-89d5-26cce304bf9c",
    "version": 3
}
Copy the code

The Key String format uses Key Function (KDF) and is also known as the Core Scaling algorithm for preventing brute-force cracking, dictionary attacks, and rainbow table attacks. Simply put, the private key is not directly encrypted with a simple password. Instead, the code is stretched by repeated hashing. The hash function repeats 262144 rounds, which is the number specified by the crypto. Kdfparams.n parameter in the keystring JSON file. An attacker trying to break a password by brute force would have to perform 262,144 rounds of hash for every possible password, making it nearly impossible for a password of sufficient complexity and length to be broken.

There are also software libraries that can read and write keystring formats, such as the JavaScript library Keythereum:

Github.com/ethereumjs/…

prompt

We do not recommend using non-deterministic wallets except for some simple tests. We recommend using an industry-standard HD wallet with a mnemonic seed backup.

Certainty wallet (seed) wallet

Deterministic or “seed” wallets are those where all the private keys are extended from a common seed using a one-way hash function. The seed is a randomly generated number combined with some other data, such as a private key derived from an index number or “chain code” (see HD wallet (BIP-32/BIP-44). In a deterministic wallet, a single seed is enough to recover all derived keys, so only one backup is required at creation time. At the same time, the seed can also be imported and exported for the wallet, so that all users’ keys can be easily transferred between different wallets.

HD wallet (BJP – 32 / BJP – 44)

Deterministic wallets are developed to simply derive many keys from a “seed”. The most advanced implementation of such a deterministic wallet is the HD wallet defined by bitcoin’s BIP-32 standard. HD wallet contains keys derived from a tree structure. For example, a parent key can be derived from a series of child keys, and each child key can be derived from a series of grandson keys, and the cycle continues endlessly. The tree structure can be seen as follows:

HD wallets have two major advantages over random (nondeterministic) keys. First, the tree structure can express additional organizational meanings, such as when a particular branch of a subkey is used to receive roll-in payments and a different branch is used to receive changes to roll-out payments. Branches of the key can also be used in common Settings, such as assigning different branches to departments, subsidiaries, specific functions, or different billing categories.

The second advantage is that users can use HD wallet to create a series of public keys without using the associated private keys. The HD wallet can then be used as a secure service or just a service to watch and receive, but the wallet itself has no private key, so it can’t spend money.

Seeds and Mnemonic words (BIP-39)

HD wallets are a powerful mechanism for managing multiple keys and addresses. When combined with a standardized method of creating seeds from a list of English words (or words from other languages), copying, exporting, and importing through the wallet becomes much easier to use. This is known as a mnemonic as defined by standard BIP-39. Today, many Ethereum wallets (and other digital currency wallets) use this standard to import and export seeds and use a common mnemonic for backup and recovery.

Let’s look at it from a practical point of view. Which of these seeds is better at copying, writing on paper, and dyslexia?

A deterministic wallet seed in hexadecimal code

FCCF1AB3329FD5DA3DA9577511F8F137
Copy the code

A wallet seed consisting of 12 words of mnemonic words

wolf juice proud gown wool unfair
wall cliff insect more detail hub
Copy the code

Wallet Best Practices

With the gradual maturity of digital currency wallet technology, a common industry standard has been gradually formed, which greatly improves the interoperability, ease of use, security and flexibility of wallet. These standards also allow wallets to derive different keys for various digital currencies from a single mnemonic. These common criteria are the following:

  • Mnemonic words based on BIP-39

  • HD wallet based on BIP-32

  • Multi-purpose HD wallet structure based on BIP-43

  • Multi-currency multi-account wallet based on BIP-44

These standards may change, and they may be discarded by future developers, but for now they form a group of interlocking technologies that have become the de facto wallet standard for most digital currencies.

These standards have been adopted by most software and hardware wallets, making them common to each other. A user can export a mnemonic from any of these wallets, import it into another wallet, and recover all transactions, keys, and addresses.

Many software wallets support this standard, such as (alphabetically) Jaxx, MetaMask, And MyEtherWallet (MEW). Hardware wallets have Keepkey, Ledger, and Trezor.

The following sections explain these techniques in detail.

prompt

If you are implementing an Ethereum wallet, it should be an HD wallet, and the seed will be encoded as a mnemonic for backup. Standards biP-32, BIP-39, BIP-43, and BIP-44 are detailed in the following sections.

Word mnemonic (BJP – 39)

A mnemonic is a sequence of words representing a random number that is seeded into a deterministic wallet. The sequence of words can again create seeds, wallets, and all derived keys. An application that implements a deterministic wallet mnemonic will show the user a sequence of 12 to 24 words when the wallet is first created. This sequence is a backup of the wallet, which can be used to recover and rebuild all keys on any compatible wallet. Mnemonics make it easier for users to back up their wallets because they are more readable and copy correctly than a set of random mnemonics.

prompt

Mnemonics are often confused with “brain wallets”. But they are not the same thing. The main difference is that the brain wallet is made up of words chosen by the user, while the mnemonic words are created randomly by the wallet on behalf of the user. This important distinction makes mnemonics safer because human randomness has few sources.

Mnemonic encoding is defined in BIP-39. Note that BIP-39 is just an implementation of mnemonic encoding. There are many different standards. Bitcoin wallet Electrum uses a different set of words before BIP-39. Bip-39 is a standard developed by the company behind Trezor, a hardware wallet, and is compatible with Electrum’s implementation. However, biP-39 now has broad industry support and is compatible with more than a dozen interoperating implementations, so BIP-39 should be the industry standard for now. Also, BIP-39 can be used to generate a multi-currency wallet that supports Ethereum, which Electrum’s seed does not.

The BIP-39 standard defines the next nine steps in mnemonic encoding and seed generation. For clarity, the whole process is divided into two parts: step 1 to step 6 generates the mnemonic word, and step 7 to step 9 generates the mnemonic word to the seed.

Generate mnemonic words

The mnemonic words are automatically generated by the wallet using a standardized process defined in BIP-39. The wallet starts with an entropy source, then adds a checksum and maps the entropy to an array of words.

  1. Create a random sequence of 128 to 256 bits (entropy)

  2. The checksum of this random sequence is created by taking the first (entropy length divided by 32) bits of SHA256.

  3. Adds the checksum to the end of the random sequence.

  4. Divide the sequence into 11-bit sections.

  5. Map each 11-bit value to a word from a predefined dictionary of 2048 words.

  6. Mnemonic coding is a series of words.

Generating entropy and encoding it into mnemonic words will show how entropy generates mnemonic words.

Mnemonic coding: Entropy and Word Length Shows the relationship between the size of entropy data and the length of mnemonic words in a word.

Mnemonic encoding: entropy and word length
Entropy (bits) Checksum (bits) Entropy + checksum (bits) Mnemonic length (words)

128

4

132

12

160

5

165

15

192

6

198

18

224

7

231

21

256

8

264

24

From mnemonic words to seeds

Mnemonic words represent entropy of 128 to 256 bits. This entropy generates a longer (512-bit) seed through the key stretch function PBKDF2. This seed then constructs a deterministic wallet and derives its key.

The key stretch function takes two parameters: a mnemonic and salt. The purpose of salt is to make it harder to brute force build query tables. Salt serves an additional purpose in standard BIP-39, and the cipher acts as an additional security factor to protect the seed, which is detailed in optional cipher in BIP-39.

Steps 7 through 9:

  1. The mnemonic generated in step 6 of the first parameter of key stretch function PBKDF2.

  2. The second parameter of the key stretch function PBKDF2 is salt. The salt consists of the string constant “mnemonic” and an additional user-supplied password string concatenation.

  3. PBKDF2 uses hMAC-SHA512 algorithm to run 2048 rounds of hashing to stretch the mnemonic and salt to produce a 512-bit value as the final output. This 512 bit value is the seed.

[fig_5_7] shows how a mnemonic produces a seed.

prompt

The key stretch function and its 2048-round hash are an effective protection against brute force cracking of mnemonics and passwords to some extent. It is expensive to constantly try out thousands of combinations of passwords and mnemonic words, and the number of combinations is like a sea (2512).

The table below shows examples of the types of mnemonic_128_no_pass, #mnemonic_128_w_pass, and #mnemonic_256_no_pass and the seeds (without passwords) they produce, respectively.

Mnemonic code for 128-bit entropy, a seed generated without a password

Entropy input (128 bits)

0c1e24e5917779d297e14d45f14e1a1a

Mnemonic (12 words)

army van defense carry jealous true garbage claim echo media make crunch

Passphrase

(none)

Seed (512 bits)

5b56c417303faa3fcba7e57400e120a0ca83ec5a4fc9ffba757fbe63fbd77a89a1a3be4c67196f57c39 a88b76373733891bfaba16ed27a813ceed498804c0570
128-bit entropy mnemonic code with cipher-generated seeds

Entropy input (128 bits)

0c1e24e5917779d297e14d45f14e1a1a

Mnemonic (12 words)

army van defense carry jealous true garbage claim echo media make crunch

Passphrase

SuperDuperSecret

Seed (512 bits)

3b5df16df2157104cfdd22830162a5e170c0161653e3afe6c88defeefb0818c793dbb28ab3ab091897d0 715861dc8a18358f80b79d49acf64142ae57037d1d54
Mnemonic code for 256-bit entropy, seed without code generation

Entropy input (256 bits)

2041546864449caff939d32d574753fe684d3c947c3346713dd8423e74abcf8c

Mnemonic (24 words)

cake apple borrow silk endorse fitness top denial coil riot stay wolf luggage oxygen faint major edit measure invite love trap field dilemma oblige

Passphrase

(none)

Seed (512 bits)

3269bce2674acbd188d4f120072b13b088a0ecf87c6e4cae41657a0bb78f5315b33b3a04356e53d062e5 5f1e0deaa082df8d487381379df848a6ad7e98798404

Optional password in BIP-39

The BIP-39 standard allows users to use an optional password when generating seeds. If no cipher is used, the mnemonic is stretched by a salt made up of the constant string “mnemonic”, which then produces a specific 512-bit seed from the given mnemonic. If a cipher is used, the stretch function produces a different seed using the same mnemonic. In fact, given a mnemonic, each possible password generates a different seed. And there are basically no “wrong” passwords. All passwords are available and all passwords can generate different seeds, and these different mnemonics form a large set of initialized wallets. The number of possible wallets is so large (2,512) that the likelihood of brute force and accidental guesses is virtually zero, provided the password is of sufficient complexity and length.

prompt

There are no “wrong” passwords in standard BIP-39. Each password generates a wallet, or a new wallet if it is not the password used before.

The optional password produces two important features:

  • A second factor that needs to be remembered prevents a copy of the mnemonic from being stolen.

  • The choice of password appears to have the ability to credibly-reject or “jail wallet”, so that wallets with small amounts of money often distract attackers from those with “truly” large amounts of money.

However, it is important to note that there is a risk of password loss when using passwords.

  • If the owner of the wallet is incapacitated or dies, then no one knows the password or what the seed is, and all the money stored in the wallet is lost.

  • Conversely, if the owner of the wallet backs up the password in the same place as the seed, it loses the purpose of the second factor.

While passwords are useful, they should also be used in conjunction with a carefully planned backup and recovery process that allows for the possibility of the wallet owner surviving and allowing their family to recover the digital currency assets.

Mnemonic work

Bip-39 has libraries implemented in many different programming languages:

Python-mnemonic references a version of Python proposed by the SatoshiLabs team in BIP-39

Consensys/ Eth-Lightwallet is a lightweight JS Ethereum wallet for nodes and browsers (based on BIP-39)

NPM/BIP39 JavaScript implementation of bitcoin BIP39: Mnemonic encoding for generating deterministic keys

There is also a BIP-39 generator implemented in a separate web page that is useful for testing and experimentation. The BIP-39 generator shows a separate web page that generates a mnemonic, seed, and extended private key.

Web pages (iancoleman. Making. IO/bip39) can be used in the browser offline (online can also, of course).

Create an HD wallet from the seed

HD wallets are created from a root seed, which is usually a random 128, 256, or 512 bit number. Normally, this seed is generated by a mnemonic word.

Each key in the HD wallet is derived from the root seed, making it possible to recreate the entire HD wallet in other compatible wallets from this seed. It also makes it easy to back up, restore, export, and import wallets containing thousands of keys, simply by transferring the mnemonic derived from the root seed.

[[bip32_bip43/44]] = = = = layered deterministic wallet (BJP – 32) and path (BJP – 43/44)

Most HD wallets follow the BIP-32 standard, which is also the de facto industry standard for determining key generators. Detailed instructions can be found at the following link:

Github.com/bitcoin/bip…

We won’t talk about biP-32 here, we just need to understand the part of the wallet that uses it. There are also many implementations of biP-32 collaborating with each other in other software libraries.

Consensys/ Eth-Lightwallet is a lightweight JS Ethereum wallet for nodes and browsers (based on BIP-39)

There is also a web version of the standard BIP-32 generator that is useful for testing and experimentation.

bip32.org/

prompt

This single BIP-32 generator is not an HTTPS site. Just to show you that this tool is not safe to use. It’s just for testing purposes. You should not use the keys generated by this web page in a production environment (real money).

Expand public and private keys

In BIP-32 terminology, a parent key can be extended to produce a “son”, which is the extended key. If it is a private key, then it is an extended private key, distinguished by the prefix XPRV:

xprv9s21ZrQH143K2JF8RafpqtKiTbsbaxEeUaMnNHsm5o6wCW3z8ySyH4UxFVSfZ8n7ESu7fgir8imbZKLYVBxFPND1pniTZ81vKfd45EHKX73
Copy the code

An extended public key is distinguished by the prefix xpub:

xpub661MyMwAqRbcEnKbXcCqD2GT1di5zQxVqoHPAgHNe8dv5JP8gWmDproS6kFHJnLZd23tWevhdn4urGJ6b264DfTGKr8zjmYDjyDTi9U7iyT
Copy the code

A very useful role in HD wallets is to derive a child public key from the parent public key, without the private key. This gives us two ways to derive the child public key: from the child private key or directly from the parent public key.

An extended public key can derive all public keys (and only public keys) from the structure of an HD wallet.

In any case where the deployed service or application has an extended public key and no private key, this shortcut can create a very secure public key. This deployment can generate an infinite number of public keys and Ethereum addresses, but it can’t cost any money to send them. At the same time, on another, more secure server, the extended private key can derive all related private keys used to sign the transaction and cost money.

A common use of this solution is to install an extended public key on a Web server to serve e-business applications. The web server can use public-key derived functions to create a new Ethereum address for each transaction, such as a customer’s shopping cart. The web server doesn’t have any private keys so thieves can’t steal it. The only way to do this without HD wallets is to generate thousands of Ethereum addresses on a partitioned secure server and preload them on an e-commerce server. This approach is inefficient and cumbersome, and requires frequent maintenance to ensure that e-commerce servers do not leak keys.

Another common application is cold storage and hardware wallets. In this scenario, the extended private key can be stored in the hardware wallet, but the extended public key can be placed online. Users can create recipient addresses as they wish, and the private key is stored securely offline. To spend the money, users can use the extended private key on an Offline signing Ethereum client or a hardware wallet that supports transaction signing.

Hardening key derivation

The ability to derive a branch of public key from XPUB is useful, but also risky. Knowing XPUB does not mean knowing the subkey. However, because XPUB contains chain keys, if a subkey is known or exposed, it can be used to derive all other subkeys along with the chain keys. A single leaked child key and a parent chain code together can expose all child private keys. To make matters worse, the child private key and the parent chain code together can also infer the parent private key.

To avoid this risk, HD Wallet uses another derivative function called hardened derivation, which “breaks” the link between the parent public key and the child chain code. The hardening derivation function uses the parent private key to derive the child chain code, not the parent public key. This creates a “firewall” in the parent or child sequence that does not threaten the security of the parent or child private key.

To put it simply, if you don’t want to risk giving away your own chain code, and you want the convenience of using XPUB to derive public key branches, you should derive it by hardening the parent, not a normal parent. The best practice is that level-1 children of the primary key are always derived by hardening to prevent threats to the primary key.

Normal derived and hardened derived exponents

The derived function in BIP-32 uses an exponent of a 32-bit integer type. To make it easier to distinguish the keys generated by normal and hardened derived functions, the exponent is divided into two intervals. 0 to 231 — 1 (0x0 to 0x7FFFFFFF) is used only to indicate normal derivations. 231 to 232 — 1 (0x80000000 to 0xFFFFFFFF) are only used to indicate hardened derivations. Therefore, if the exponent is less than 231, the child is normal, and if the exponent is greater than or equal to 231, the child is hardened.

For better index readability and display, the index for sclerosing children is displayed from zero (with a prime number that fits). The first normal child key is displayed as 0, so the first hardened child (index 0x80000000) is displayed as 0. . The second hardened key index starts at 0x80000001 and is displayed as 1′ And so on. When you see an HD wallet with an index of I ‘ Phi, that means 231 plus I.

HD Wallet key Identifier (path)

The keys in an HD wallet are identified by the “path” naming convention, separated by the slash (/) character for each level of the tree (see the HD wallet path example). All private keys derived from the master private key begin with “m.”. The public key derived from the master public key starts with “M.”. So the first child of the master private key is m/0. The first child of the master public key is M/0. The second grandchild of the first child is m/0/1, and so on.

The “ancestor” of a key is read from right to left until its own master key is derived. For example, the identifier M /x/y/z is the ZTH subkey of M /x/y, the yth subkey of M /x, and the x subkey of M.

Example HD wallet path
HD path Key described

m/0

The first (0) son of primary private key M

m/0/0

First grandchild (m/0) first grandchild private key

m/0’/0

First sclerotic offspring (m/0′) first standard grandchild

m/1/0

Second child (m/1) first grandchild private key

M/23/17/0/0

The public key of the 24th child’s 18th grandchild’s first great-grandchild’s first great-great-grandchild

Tree structure guide for HD wallet

The HD Wallet’s tree structure offers great flexibility. Each parent extended key can have 4 billion children: 2 billion ordinary children and 2 billion hardened children. For every generation there are another four billion, and so on. This tree can go on from generation to generation if you want. But this flexibility makes operating on this infinite tree structure complicated. In particular, moving HD wallet between implementations can be particularly difficult, as the possibilities of this internal structure from branch to sub-branch are infinite.

Both current BIPs address these complexities by creating some standards for the tree structure of HD wallets. Bip-43 proposes the first hardener index as a special identifier that can represent the “use” of tree structures. Bip-43 argues that HD wallets should only use a branch of the level-1 tree structure and let the index identify the structure and the namespace of the remaining numbers by defining its purpose. For example, an HD wallet uses only branches. /, and intends to use it to indicate a particular use, which is identified by the exponent “I”.

To clarify the details, the proposed multi-currency, multi-account structure of the BIP-44 is the “utility” number 44′ of the BIP-43. All HD wallets follow the BIP-44 structure, which is actually identified using a branch m/44’/ of the tree structure.

Bip-44 also specifies five predefined tree hierarchies:

m / purpose' / coin_type' / account' / change / address_index
Copy the code

The first level “purpose” is always equal to 44′. The second tier, “coin_type, “identifies the type of digital currency, and for multi-currency HD wallets each currency has its own subtree below the second tier. Here are a few currencies defined in the standards documentation called SLIP0044:

Github.com/satoshilabs…

For example: Ethereum is M /44; /60' , the Etheric classics are M /44' /61' , bitcoin is m/44. /0' The test network for all of these currencies is m/44. /1' .

The third tier is “account”, which allows users to subdivide their wallets into logical sub-accounts for accounting or organizational purposes. For example, an HD wallet can contain two Ethereum “accounts” : M /44' /60' /0' And m / # 44 & x27; /60' /1' . And each account is the root of its own subtree.

Because BIP-44 was originally created for Bitcoin, it contains “quirk” that has nothing to do with Ethereum. The fourth level of the path is “change”. An HD wallet has two subtrees, one for receiving addresses and one for changing addresses. Ethereum, on the other hand, only has “receive” addresses and does not need to change addresses. Note that since the previous level used hardened derivations, this level is plain derivations. This is so that the tree at this level can export public keys that can be used in an insecure environment. The available addresses are derived from the HD wallet as children of the fourth tier, which then forms the “address_index” of the fifth tier of the tree. For example, ethereum’s third recipient address will be paid in the main account as M/44. /60′ /0′ /.two survivors. Bip-44 HD wallet structure example:

Example of BIP-44 HD wallet structure
HD path The key to describe

M/44' /60' /0' /.two survivors

The third received public key for the master Ethereum account

M/44' /0' /3' / 1/14

The public key for the 15th variable address of the fourth Bitcoin account

m/44' /2' /0' / 0/1

The second private key used to sign the litecoin primary account

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.