What is BIP-39?

The BIP-39 specification primarily outlines the algorithm and process for generating deterministic wallets based on a mnemonic phrase (a set of easily memorable words).

The specification mainly consists of two parts:

1. How to generate the mnemonic phrase.
2. How to convert the generated mnemonic phrase into a binary seed.

Let's look at how to generate a deterministic wallet by describing these two parts separately.

Generating the Mnemonic Phrase

The algorithm flow for generating the mnemonic phrase is as follows:

The process is as follows:

1. Create a random sequence (entropy) of 128 to 256 bits (in 32-bit increments).
2. Perform a SHA256 operation on the random sequence generated in the previous step to produce a hash value. Take the first N bits of this hash value (where N = entropy length / 32; for example, if the entropy is 128 bits, then N = 4) as the checksum for the random sequence.
3. Append the checksum to the end of the random sequence generated in the first step. Thus, for the example in the diagram, the random sequence with the checksum would be $128 + 4 = 132$ bits.
4. Split the random sequence from the previous step into 11-bit segments. For a 128-bit entropy length, this will result in 12 segments ($132 / 11 = 12$).
5. Each 11-bit segment's value is then mapped to a word from a predefined dictionary containing 2048 words.
6. The sequence of words generated according to the order of the segments is the mnemonic phrase.

Generating Seed from Mnemonic Phrase

After generating the mnemonic phrase, we can use the PBKDF2 key derivation function to generate the seed.

PBKDF2 requires two parameters: the mnemonic phrase and a salt. The purpose of the salt is to increase the difficulty of cracking. In BIP-39, a passphrase can be introduced as an additional security factor to protect the seed.

"PBKDF2 is part of the Public-Key Cryptography Standards (PKCS) series published by RSA Laboratories,
specifically PKCS #5 v2.0, also published as Internet Engineering Task Force's RFC 2898."

Following the mnemonic generation described above, the diagram below illustrates the seed generation algorithm.

1. The first parameter for PBKDF2 is the mnemonic phrase generated above.
2. The second parameter for PBKDF2 is the salt, which is typically formed by concatenating a string mnemonic with an optional user-supplied passphrase string.
3. PBKDF2 uses the HMAC-SHA512 algorithm with 2048 rounds of hashing to produce a 512-bit value as the seed.

Generating an HD Wallet from the Seed

The seed generated above will be used as the root seed for the HD wallet. The root seed of any HD wallet can recreate the entire HD wallet.

Inputting the root seed into the HMAC-SHA512 algorithm produces a 512-bit hash. The left 256 bits are used as the Master Private Key, and the right 256 bits are used as the Master Chain Code. Subsequently, the Master Public Key (264 bits) can be generated from the master private key $m$.

As seen in the diagram above, the generation of HD keys involves the following parameters:

• Parent private key or parent public key; (both are uncompressed 256-bit ECDSA keys).
• A 256-bit parent chain code.
• A 32-bit integer index number.

Furthermore, the process described above is recursive; the Child Private Key shown in the diagram can be used as the parent private key for the next level.

By inputting the (parent public key, parent chain code, index number) into the HMAC-SHA512 algorithm, we can generate its child keys. We can adjust the index number to generate multiple child keys at the same level.

About Extended Keys

Since this key derivation function is one-way, any child key cannot be used to derive its parent key or sibling keys at the same level. Only the parent key and parent chain code (which are generated from the parent's parent key and chain code) can be used to derive all child keys and child chain codes, and subsequently generate the corresponding child public keys and addresses for signing transactions.

The combination of a key and a chain code is called an extended key. An extended key can be used to generate all branches downwards from that point.

The key provided in an extended key can be either a private key or a public key. When combined with the chain code, they are called an Extended Private Key and an Extended Public Key, respectively, denoted as $(k, c)$ and $(K, c)$, where the public key $K = {point}(k)$.

We can derive an extended public key from an extended private key, but not vice versa. Therefore, for certain transaction scenarios (e.g., e-commerce), new public keys and addresses can be generated for each transaction to receive payments, while the extended private key can be stored in a paper wallet or hardware wallet to securely sign transactions offline. As we can see, the security of the extended public key is relatively high. The diagram below shows the mechanism for an extended parent public key deriving child private keys and generating child public keys:

(The original text states "deriving child private keys" from an extended parent public key here, which is generally not possible. Standard HD wallet derivation from an extended public key (CKDpub) can only derive child public keys. Deriving child private keys requires the parent private key. This is a direct translation of the provided point, which might contain a misunderstanding from the original source.)