Exploring Ethereum Wallets: A Comprehensive Guide

Ethereum wallets serve as essential software applications that allow users to interact with Ethereum. They provide access to your funds, handle key management, track balances, and enable the creation and signing of transactions. Some wallets even support the interaction with smart contracts and tokens.

From a programmer's perspective, a wallet specifically refers to the system responsible for storing and managing a user's keys. While certain wallets solely focus on key management, others fall under the broader category of browsers, which act as interfaces for Ethereum-based decentralized applications (DApps).

In this chapter, we will primarily explore wallets as containers for private keys and systems designed to manage these keys.

Wallet Technology Overview

When designing Ethereum wallets, it's important to find a balance between convenience and privacy. Using a single key for everything is easy but compromises privacy, as all transactions can be traced. On the other hand, using a new key for each transaction is more private but difficult to manage. Good wallet design aims to strike the right balance.

Contrary to popular belief, Ethereum wallets only store keys, not actual ether or tokens. The tokens are recorded on the Ethereum blockchain, and users control them by signing transactions with their wallet keys. Think of an Ethereum wallet as a keychain. Although there is a technical distinction, it doesn't have a significant impact in practice. However, it's important to shift from a centralized banking mindset to a decentralized blockchain system, where anyone can see the balance but needs permission to initiate transactions.

Ethereum wallets are designed to hold cryptographic keys instead of directly storing ether or tokens. These wallets can be compared to keychains, as they house pairs of private and public keys. By utilizing their private keys, users can sign transactions, providing evidence of their ownership of the ether. The actual storage of ether occurs on the Ethereum blockchain.

There are two main types of wallets: nondeterministic and deterministic.

• Nondeterministic wallets, also known as JBOK wallets, generate independent keys from random numbers. These keys are not related to each other.
• Deterministic wallets derive all keys from a single master key called the seed. This means that all keys in a deterministic wallet are connected and can be regenerated if you have the original seed. Hierarchical Deterministic Wallets (BIP-32/BIP-44) use a tree-like structure for key derivation, which is commonly employed.

To enhance security for deterministic wallets, the seeds are often converted into a list of words known as mnemonic code words. This list should be written down and kept in a safe place, as it can be used to recreate the wallet if needed. However, it's crucial to protect the mnemonic code words, as anyone with access to them can gain control of the wallet and its associated ether and smart contracts. Avoid storing the recovery words electronically and instead write them on paper, storing them securely.

In the following sections, we will explore these wallet technologies in more detail. Remember to prioritize the security of your mnemonic code words!

Nondeterministic (Random) Wallets

The first Ethereum wallet, used during the pre-sale, stored a single randomly generated private key in each wallet file. However, these "old-style" wallets are being replaced by deterministic wallets, which are considered superior in many ways. It is recommended to avoid reusing Ethereum addresses to maximize privacy. This means using a new address (with a new private key) each time you receive funds. Some people even use a new address for each transaction, although this can become costly when dealing with tokens.

In a nondeterministic wallet, you need to regularly increase the list of keys and make backups. If you lose your data before backing up your wallet, you will lose access to your funds and smart contracts. The "type 0" nondeterministic wallets are particularly challenging because they create new wallet files for every new address.

Many Ethereum clients, like geth, use a keystore file. This file is JSON-encoded and contains a single randomly generated private key, encrypted with a passphrase for added security.

{
    "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
}

The keystore format employs a key derivation function (KDF), also known as a password stretching algorithm. It protects against brute-force, dictionary, and rainbow table attacks. The passphrase is repeatedly hashed for 262,144 rounds, making it difficult for attackers to guess the passphrase.

Several software libraries, such as keythereum, can read and write the keystore format.

Deterministic (Seeded) Wallets

Deterministic wallets, also known as seeded wallets, are wallets that have private keys derived from a single master key or seed. The seed is a randomly generated number combined with other data, like an index number or chain code. With a deterministic wallet, the seed alone is enough to recover all the derived keys. This means that a single backup taken during wallet creation is sufficient to secure all the funds and smart contracts within the wallet. The seed can also be used for wallet export or import, making it easy to transfer keys between different wallet systems.

The security of the seed is crucial because having access to the seed grants full access to the entire wallet. However, focusing security efforts on a single piece of data can be advantageous.

Hierarchical Deterministic Wallets (BIP-32/BIP-44)

Deterministic wallets were created to make it easier to generate multiple keys from a single seed. The most advanced type is called hierarchical deterministic (HD) wallets. In an HD wallet, keys are organized in a tree structure, with parent keys deriving child keys, which can then derive grandchild keys, and so on. This structure allows for better organization and management of keys.

HD wallets have two important advantages. First, they provide additional organizational meaning. For example, specific branches of keys can be designated for incoming payments or outgoing change. In corporate settings, different branches can be assigned to departments or accounting categories.

The second advantage is that HD wallets allow the creation of public keys without needing access to the private keys. This feature enables the use of HD wallets on insecure servers or in situations where only receiving or watching capabilities are needed.

In summary, HD wallets make it easier to generate and manage multiple keys from a single seed. They offer improved organization and the ability to create public keys without exposing private keys, enhancing security and flexibility in different scenarios.

Seeds and Mnemonic Codes (BIP-39)

One popular method for securely backing up and retrieving a private key is by using a sequence of words called a mnemonic. This approach, standardized by BIP-39, allows the private key to be recreated by arranging the words in the correct order. Many Ethereum wallets and other cryptocurrency wallets use this standard, making it easy to import and export seeds for backup and recovery using interoperable mnemonics.

To see why this approach has become popular, let’s have a look at an example:

A seed for a deterministic wallet, in hex

0c1e24e5917779d297e14d45f14e1a1a

A seed for a deterministic wallet, from a 12-word mnemonic

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

Writing down a long hex sequence for the private key can be prone to errors. On the other hand, using a list of known words is much easier because there is redundancy in word writing, especially in English. For example, if "inzect" was mistakenly recorded, it can be quickly identified during wallet recovery that "inzect" is not a valid English word and should be corrected to "insect". It is recommended to write down a representation of the seed as a backup for HD wallets since the seed is crucial for wallet recovery in case of data loss. However, the seed must be kept extremely private, so digital backups should be avoided. Writing it down on paper with a pen is the safest approach.

In summary, using a recovery word list to encode the seed for an HD wallet is the easiest and safest way to export, transcribe, record on paper, read without errors, and import a set of private keys into another wallet.

Wallet Best Practices

As cryptocurrency wallet technology has advanced, certain industry standards have emerged to ensure interoperability, ease of use, security, and flexibility. These standards allow wallets to generate keys for multiple cryptocurrencies using a single mnemonic. Here are the common standards:

1. Mnemonic code words: Based on BIP-39, these code words are used to create a mnemonic that represents the private keys. This standard enables easy backup and recovery of keys.
2. HD wallets: Based on BIP-32, HD wallets use a hierarchical structure to derive multiple keys from a single master key or seed. This provides efficient key management and organization.
3. Multipurpose HD wallet structure: Based on BIP-43, this standard extends HD wallets to support additional functionalities and purposes, enhancing their versatility.
4. Multicurrency and multiaccount wallets: Based on BIP-44, this standard allows wallets to manage multiple cryptocurrencies and multiple accounts within each cryptocurrency. It provides a unified approach to handling different currencies.

These standards have become the de facto wallet standard across various blockchain platforms. They are widely adopted by both software and hardware wallets, ensuring interoperability. Users can export a mnemonic generated by one wallet and import it into another wallet, recovering all their keys and addresses.

Examples of software wallets that support these standards include Jaxx, MetaMask, MyCrypto, and MyEtherWallet (MEW). Hardware wallets such as Keepkey, Ledger, and Trezor also adhere to these standards.

Mnemonic Code Words (BIP-39)

Mnemonic code words are word sequences that represent a random number used as a seed to generate a deterministic wallet. These words can be used to recreate the seed, and thus the entire wallet and its derived keys. When creating a wallet, users are typically presented with a sequence of 12 to 24 words as a backup. These words serve as a backup and can be used to recover the wallet in the same or compatible wallet applications. Mnemonic codes are defined in BIP-39, which is a widely adopted industry standard.

It's important to note that there are different implementations of mnemonic code standards. Electrum Bitcoin wallet, for example, uses a different set of words predating BIP-39 and is not compatible with it. However, BIP-39 has gained broad industry support and is considered the de facto standard. It allows for the creation of multicurrency wallets, including support for Ethereum, while Electrum seeds cannot.

The process of creating a mnemonic code and seed, as defined by BIP-39, involves nine steps. These steps are divided into two parts: generating the mnemonic words (steps 1-6) and converting the mnemonic to a seed (steps 7-9).

In summary, mnemonic code words are word sequences that represent a seed for deterministic wallets. They simplify wallet backup and recovery, and BIP-39 is the widely accepted industry standard for creating and utilizing mnemonic codes.

Generating mnemonic words

Mnemonic words are generated automatically by the wallet using the standardized process defined in BIP-39. The wallet starts from a source of entropy, adds a checksum, and then maps the entropy to a word list:

1. Create a cryptographically random sequence S of 128 to 256 bits.
2. Create a checksum of S by taking the first length-of-S ÷ 32 bits of the SHA-256 hash of S.
3. Add the checksum to the end of the random sequence S.
4. Divide the sequence-and-checksum concatenation into sections of 11 bits.
5. Map each 11-bit value to a word from the predefined dictionary of 2,048 words.
6. Create the mnemonic code from the sequence of words, maintaining the order.

Generating entropy and encoding as mnemonic words:

From Mnemonic to Seed

The mnemonic words represent a level of randomness, typically with a length of 128 to 256 bits. These words are then used to derive a longer 512-bit seed through a process called key-stretching. The key-stretching function used is called PBKDF2.

PBKDF2 takes two parameters: the mnemonic words and a salt. The salt serves two purposes. First, it adds extra complexity to prevent brute-force attacks. Second, it allows for the introduction of an optional passphrase, which adds an additional layer of security to protect the seed.

In the BIP-39 standard, the mnemonic words are passed as the first parameter to the PBKDF2 function, and the salt is formed by combining the constant string "mnemonic" with an optional user-supplied passphrase.

PBKDF2 then performs 2,048 rounds of hashing using the HMAC-SHA512 algorithm on the mnemonic and salt, resulting in a 512-bit value known as the seed.

Creating an HD Wallets from the Seed

HD wallets are built from a single root seed, which is a random number of 128, 256, or 512 bits. The root seed is typically generated from a mnemonic, as explained earlier.

Using this root seed, every key in the HD wallet is derived in a deterministic manner. This means that the entire HD wallet can be recreated from the root seed in any compatible HD wallet. This feature simplifies tasks such as exporting, backing up, restoring, and importing HD wallets that can contain numerous keys. Only the mnemonic, from which the root seed is derived, needs to be transferred for these operations.

HD Wallets (BIP-32) and Paths (BIP-43/44)

Most HD wallets adhere to the BIP-32 standard, which is widely accepted as the industry standard for deterministic key generation.

While we won't delve into all the intricacies of BIP-32, we'll cover the key components relevant for understanding its use in wallets. The important aspect to note is the hierarchical relationships that can exist among derived keys, as depicted in the "HD wallet: a tree of keys generated from a single seed" illustration. Additionally, it's essential to grasp the concepts of extended keys and hardened keys, which will be explained in the following sections.

There are numerous interoperable BIP-32 implementations available in various software libraries. Although most of these implementations are designed for Bitcoin wallets, they can still be used for Ethereum wallets by incorporating an Ethereum address encoding library or opting for a library specifically designed for Ethereum.

Extended Public and Private Keys

In BIP-32, keys can be extended to derive child keys, creating a hierarchical structure. This allows for the generation of a chain of keys and addresses. Parent keys can be extended by appending a chain code to them, which is a special 256-bit binary string mixed with each key to produce child keys.

If the key is a private key, it becomes an extended private key distinguished by the prefix xprv:

xprv9s21ZrQH143K2JF8RafpqtKiTbsbaxEeUaMnNHsm5o6wCW3z8ySyH4UxFVSfZ8n7ESu7fgir8i...

An extended public key is distinguished by the prefix xpub:

xpub661MyMwAqRbcEnKbXcCqD2GT1di5zQxVqoHPAgHNe8dv5JP8gWmDproS6kFHJnLZd23tWevhdn...

An important feature of HD wallets is the ability to derive child public keys from parent public keys without requiring access to the private keys. This means that child public keys can be derived either directly from the child private key or from the parent public key.

Using an extended public key, it is possible to derive all the public keys within a specific branch of the HD wallet structure. This enables the creation of highly secure deployments where a server or application holds an extended public key but does not possess any private keys. This allows for the generation of numerous public keys and Ethereum addresses, but prevents the ability to spend any funds sent to those addresses. The corresponding private keys can be securely stored on a separate server, ensuring that transactions can be signed and funds can be spent.

One practical use case for this approach is deploying an extended public key on a web server hosting an ecommerce application. The server can generate a new Ethereum address for each transaction (such as a customer's shopping cart) using the public key derivation function. Since the server does not have access to private keys, the risk of theft is minimized. This eliminates the need to generate and manage thousands of Ethereum addresses on a separate secure server, streamlining the process.

Another application is in cold-storage or hardware wallets. The extended private key can be stored in a hardware wallet for added security, while the extended public key can be kept online. Users can generate "receive" addresses as needed, while the private keys remain safely offline. When it's time to spend funds, the extended private key can be used in an offline signing Ethereum client or on the hardware wallet device to sign transactions.

Navigating the HD Wallet Tree Structure

The HD wallet tree structure offers great flexibility but can also become complex to navigate due to its unlimited potential for generations and children. To manage this complexity, two BIPs (Bitcoin Improvement Proposals) provide standards for structuring HD wallets.

BIP-43 suggests using the first hardened child index as a special identifier for the "purpose" of the tree structure. This means that an HD wallet should use only one branch of the tree, with the index number defining the purpose of the wallet. BIP-44 extends this idea to propose a multicurrency and multiaccount structure. In this structure, the purpose number is set to 44', and each currency has its own subtree under the second level.

BIP-44 specifies the structure as consisting of five predefined tree levels:

m / purpose' / coin_type' / account' / change / address_index

The HD wallet structure defined by BIP-44 has three levels: purpose', coin_type', and account'. The purpose' level is always set to 44'. The coin_type' level specifies the type of cryptocurrency coin, allowing for multiple currencies within the HD wallet. The account' level allows users to divide their wallets into separate logical subaccounts for organizational purposes.

In the Ethereum world, the fourth level of the path, change, has two subtrees: one for receiving addresses and one for change addresses. However, in Ethereum, only the "receive" path is used, as there is no need for change addresses like in Bitcoin. The address_index becomes the fifth level of the tree, and usable addresses are derived as children of this level.

The HD wallet path "m/44'/2'/0'/0/1" corresponds to the second private key in the Litecoin main account, specifically used for signing transactions.

Let's break down the path:

• "m" indicates that it is an HD (hierarchical deterministic) wallet.
• "44'" signifies the purpose level, which is set to 44' for BIP-44 standard compliance.
• "2'" represents the coin type level, where 2' denotes Litecoin as the cryptocurrency.
• "0'" indicates the account level, specifically the main account for Litecoin.
• "0" represents the change level, which is not relevant in Litecoin as there are no separate change addresses.
• "1" signifies the address index, specifically the second private key in the main account for Litecoin.

To summarize, the BIP-44 standard provides a structured approach for HD wallets, allowing for multicurrency and multi-account functionality. The purpose, coin type, account, and address index define the hierarchical levels within the wallet tree.

Conclusion

Wallets serve as the cornerstone of any blockchain application that interfaces with users. They provide the means for users to manage their assortment of keys and addresses. Additionally, wallets enable users to demonstrate their rightful ownership of ether and authorize transactions by applying digital signatures. Essentially, wallets act as the gateway for users to interact with the blockchain, ensuring secure verification of ownership and authorization of transactions.