10-bip39-hdwallet-ethereum.md

Bip-39

bip-39

Generating a wallet seed phrase is an important step in creating a cryptocurrency wallet. There are many libraries in JavaScript that can help you generate a seed phrase.

Either way, here's an example of how to generate a 12-word seed phrase using the popular bip39 library in JavaScript:

// nodejs
const bip39 = require('bip39');
const crypto = require('crypto');

function generateSeedPhrase() {
  const entropy = crypto.randomBytes(16);
  const mnemonic = bip39.entropyToMnemonic(entropy.toString('hex'));

  return mnemonic.split(' ');
}

Here's how the code works:

1. We import the bip39 and crypto libraries. bip39 is used to convert random bytes into a mnemonic seed phrase, and crypto is used to generate those random bytes.

2. We define the generateSeedPhrase function, which returns a 12-word seed phrase.

3. Inside the function, we generate 16 random bytes using the crypto.randomBytes method.

4. We convert those random bytes into a 12-word seed phrase using the bip39.entropyToMnemonic method.

5. We split the resulting seed phrase into an array of 12 words and return it.

---

HD-Wallet - bip-32

bip39 is a JavaScript library that provides functionality for generating mnemonics that are used to generate a deterministic hierarchy of keys. It implements the BIP-39 standard, which provides methods for converting a random sequence of bytes into a human-readable list of words that can be used as a seed phrase for wallets.

Here's an example of how to use bip39 in JavaScript:

// nodejs
const bip39 = require('bip39');
const mnemonic = bip39.generateMnemonic();
console.log(mnemonic);

This code snippet generates a new 12-word mnemonic seed phrase using bip39.generateMnemonic(). This function uses cryptographically secure random number generators to create a sequence of random bytes, which is then converted into a mnemonic phrase according to the BIP-39 standard.

hdwallet is another JavaScript library that builds on top of bip39 to provide tools for working with Hierarchical Deterministic (HD) wallets. HD wallets allow users to generate a tree of key pairs derived from a master seed, which makes it easier to manage a large number of addresses and private keys.

Here's an example of how to use hdwallet in JavaScript:

// nodejs
const bip39 = require('bip39');
const hdkey = require('ethereumjs-wallet/hdkey');

const mnemonic = bip39.generateMnemonic();
const seed = bip39.mnemonicToSeedSync(mnemonic);

const hdwallet = hdkey.fromMasterSeed(seed);
const wallet = hdwallet.derivePath("m/44'/60'/0'/0/0").getWallet();
console.log("Address:", wallet.getAddressString());
console.log("Private key:", wallet.getPrivateKeyString());

This code snippet generates a new 12-word mnemonic seed phrase using bip39.generateMnemonic(), then converts it into a binary seed using bip39.mnemonicToSeedSync(). It then creates an hdkey object from the seed, which provides methods for deriving child keys according to a hierarchical path.

Finally, it derives an Ethereum address and private key using the path m/44'/60'/0'/0/0, which is the standard path for the first account in an HD wallet using the Ethereum derivation standard. It then logs the address and private key to the console.

Note that this code requires the ethereumjs-wallet and ethereumjs-util libraries to be installed.

---

Why m/44/60 presenting the Ethereum

HD wallets use Hierarchical Deterministic (HD) keys, which allow multiple keys to be generated from a single seed phrase. The derivation of keys is done in a deterministic way, meaning that the same seed phrase will always generate the same set of keys.

The HD wallet specification follows the BIP32 standard, which defines how keys can be derived from a root key using a hierarchical tree structure. The tree is built from a single master seed, which is derived from the user's mnemonic passphrase.

Each key in the tree is identified by a path that consists of a series of indices that indicate its position in the tree. These indices are separated by slashes ("/") and are expressed as either hardened or non-hardened indices.

A hardened index is represented by "m/i'", where the "m" indicates the root key of the tree, and the "i" represents the index of the child key. The apostrophe (') indicates that the key is a hardened key, which means that it can only be derived using the parent key's private key. This significantly improves the security of the wallet.

On the other hand, a non-hardened index is represented by "m/i", and can be derived using only the parent key's public key. These keys are less secure since they can be calculated using only public information.

In Ethereum, HD wallets typically use the "m/44'/60'/0'/0" derivation path. The "44'" index represents the BIP44 standard, which is a commonly used hierarchical deterministic key specification. The "60'" index indicates that we are using the Ethereum network, and the "0'/0" indices are used to indicate the index of the account and address to derive.

Now, let's do the math. The first index in the path, "44'", is a hardened index, which means it will be used to derive a private key. The second index, "60'", is also a hardened index, so it will be used to derive another private key. The remaining indices, "0'/0", are non-hardened indices that are used to derive the Ethereum account and address respectively.

To calculate these keys, we start with the master seed, which is a random 128-bit to 256-bit number derived from the mnemonic phrase. We then use a key-derivation function (KDF) to deterministically generate child keys from the parent key. The KDF used in BIP32 is called HMAC-SHA512, which is a cryptographically secure hash function.

To derive the first child key at index "44'", the KDF takes the master seed and generates a 512-bit value. This value is split into two halves, which are then used as the private key and chain code of the new key. The private key is then used to derive the second child key at index "60'", following the same process.

Finally, the non-hardened indices are used to derive the Ethereum account and address. Since these keys are derived using only the public keys of the parent keys, they are less secure since they can be calculated using only public information. Nonetheless, they provide a convenient way to generate a large number of keys from a single seed phrase.