6

I understand that the mnemonic is enough to recover the wallet. How are the keys and address generated from there? Does one need to have the dictionary of the mnemonic to be able to recover the wallet?

5

You need the dictionary, yes. Each word is a representation of a number, and that number is the index of the word in the dictionary. Each triplet of words maps (via their indices in the dictionary) to a 32 bit number. Use 8 of them, and you get your 256 bit seed as a bitstring.

The private spend key is the first 128 whole 256 bits (see luigi's comment below). The private view key is usually derived from a hash of the private spend key, but doesn't have to be (no seed in that case). Public keys are computed from a one way calculation from the respective private key. The address is essentially the public keys concatenated with a CRC, and turned into base58 for user friendliness.

  • 1
    The private spend key is not the first 128 bits. It's the whole 256 bits. Also, to use a mnemonic as your backup mechanism (instead of say, the spend and view private keys), you most likely want to follow the normal derivation (view key as hash of spend key). – Luigi Sep 20 '16 at 0:38
6

There's a really nice description and address generation tool here:

https://xmr.llcoins.net/addresstests.html

I believe that site is owned and maintained by core dev person luigi1111.

Long quote from luigi's page:

Cryptonote Public Addresses differ in several ways compared to Bitcoin. First, Cryptonote uses two keypairs, known as the spend keypair and the view keypair. Furthermore, these keys are EdDSA (specifically ed25519) keys, whereas Bitcoin uses ECDSA (specifically secp256k1) keys. Finally, Cryptonote Public Addresses are direct representations of the pair of public keys, whereas Bitcoin (and clones) uses a hash of the single public key. EdDSA keys (both private and public) are 256 bits long, or 64 hexadecimal characters. Not every 256-bit integer is a valid EdDSA scalar (private key); it must be less than the "curve order". The function to do this is labeled sc_reduce32.

To add to the confusion, there are presently at least three different methods of private key derivation in existence for Monero (and other Cryptonotes), though Bitcoin also has many: Original (non-deterministic) Style – The Private Spend Key and Private View Key are both independently and randomly chosen to form an account. You can simulate this above by pressing the "Random" buttons next to fields 3. and 4., then pressing "Gen 5.", "Gen 6.", and "Gen 7.", in that order. There is no good way to back up a non-deterministic account other than keeping copies of the files; you need to have a copy of both private keys, but presently only MyMonero will accept the two keys as input instead of a seed/wallet file. For these reasons, it is not recommended to use an account of this type. Mnemonic (Electrum or Deterministic) Style – In this style, the Private View Key is derived from the Private Spend Key, so you only need to remember one thing: the seed, which is actually just a representation of the Private Spend Key itself. This 256-bit scalar can be easily converted to a "24-digit" Base1626 "number" in the form of a mnemonic seed, which is 25 words long with the last word being used as a checksum. Mnemonics convert on a ratio of 4:3 minimum: four bytes creates three words, plus one checksum word; eight bytes creates six words, plus one checksum word; and so on. The "seeds" created by this method will always be valid scalars as they are sent to sc_reduce32 first. The Private View Key is derived by hashing the Private Spend Key with Keccak-256, producing a second 256-bit integer, which is then sent to sc_reduce32. You can test out this style above by pressing the "Random" button on the upper right, or by pressing either of the "Random" buttons next to fields 1. and 2., then the various "Gen x." buttons. You can backup accounts of this type by writing down or otherwise saving the 25 word deterministic seed; you can easily restore using both and MyMonero. MyMonero Style – This is similar to 2., but uses a 13 word seed instead of a 25 word seed. The 13 words convert to a 128-bit integer that is used for both spend and view key derivation, in the following form: the 128-bit integer is hashed with Keccak-256 to produce a 256-bit integer, a. a is sent to sc_reduce32, which returns the Private Spend Key. a is hashed once more with Keccak-256 to produce a second 256-bit integer, b. b is then sent to sc_reduce32, which returns the Private View Key. You may have noticed a critical difference between this style and the Electrum Style: MyMonero's Private View Key derivation is done by hashing random integer a, while Electrum Style derivation is done by hashing the Private Spend Key. This means that 13 and 25 word seeds are not compatible – it is not possible to create an Electrum Style seed (and account) that matches a MyMonero Style seed (and account) or vice versa; the view keypair will always be different. You can test out this style above with the "Random MyMonero" button. To backup MyMonero accounts, save the 13 word seed; you can currently "restore" using MyMonero only (you're really just logging in) – Simplewallet does not currently support 13-word seeds.

Above we discussed the different ways private keys are derived; the rest of the address generation process is the same in all three cases. The Private Spend Key and Private View Key are sent to the ed25519 scalarmult function to create their counterparts, the Public Spend Key and Public View Key. To create the actual Public Address, the following is performed: The pair of public keys are prepended with one network byte (the number 18, 0x12, for Monero). It looks like this: (network byte) + (32-byte public spend key) + (32-byte public view key). These 65 bytes are hashed with Keccak-256. The first four bytes of the hash from 2. are appended to 1., creating a 69-byte Public Address. As a last step, this 69-byte string is converted to Base58. However, it's not done all at once like a Bitcoin address, but rather in 8-byte blocks. This gives us eight full-sized blocks and one 5-byte block. Eight bytes converts to 11 or less Base58 characters; if a particular block converts to <11 characters, the conversion pads it with "1"s (1 is 0 in Base58). Likewise, the final 5-byte block can convert to 7 or less Base58 digits; the conversion will ensure the result is 7 digits. Due to the conditional padding, the 69-byte string will always convert to 95 Base58 characters (8 * 11 + 7). This 95-character result is the (obscenely long) Cryptonote Public Address! If you're creating an integrated address, simply append the 64-bit payment ID to step 1 and continue; everything else is the same except for the lengths (77 bytes total, 106 Base58 digits) and the prepended byte (19, 0x13).

1

I understand that the mnemonic is enough to recover the wallet. How are the keys and address generated from there?

The seed mnemonic is a wallet convention thing, and any wallet can have its own if you will. The protocol doesn't care about mnemonic or seed. All you need protocol-wise is a private spend key and a private view key, where a private key is just some number smaller than l where l is a prime order of the EC curve basepoint l=2^252 + 27742317777372353535851937790883648493. Anything bigger than that will get wrapped around ie a and a+l are equivalent. There are 2 conventions in use (for now) and the 13-word one will be deprecated AFAIK.

This site, made by one developer from the core team (Luigi1111), has a great explanation on how the whole key derivation process works, and below text is taken from the site and formatted to suit SE:

Cryptonote Public Addresses differ in several ways compared to Bitcoin. First, Cryptonote uses two keypairs, known as the spend keypair and the view keypair. Furthermore, these keys are EdDSA (specifically ed25519) keys, whereas Bitcoin uses ECDSA (specifically secp256k1) keys. Finally, Cryptonote Public Addresses are direct representations of the pair of public keys, whereas Bitcoin (and clones) uses a hash of the single public key. EdDSA keys (both private and public) are 256 bits long, or 64 hexadecimal characters. Not every 256-bit integer is a valid EdDSA scalar (private key); it must be less than the "curve order". The function to do this is labeled sc_reduce32.

To add to the confusion, there are presently at least three different methods of private key derivation in existence for Monero (and other Cryptonotes), though Bitcoin also has many:

  1. Original (non-deterministic) Style – The Private Spend Key and Private View Key are both independently and randomly chosen to form an account. You can simulate this above by pressing the "Random" buttons next to fields 3. and 4., then pressing "Gen 5.", "Gen 6.", and "Gen 7.", in that order. There is no good way to back up a non-deterministic account other than keeping copies of the files; you need to have a copy of both private keys, but presently only MyMonero will accept the two keys as input instead of a seed/wallet file. For these reasons, it is not recommended to use an account of this type.
  2. Mnemonic (Electrum or Deterministic) Style – In this style, the Private View Key is derived from the Private Spend Key, so you only need to remember one thing: the seed, which is actually just a representation of the Private Spend Key itself. This 256-bit scalar can be easily converted to a "24-digit" Base1626 "number" in the form of a mnemonic seed, which is 25 words long with the last word being used as a checksum. Mnemonics convert on a ratio of 4:3 minimum: four bytes creates three words, plus one checksum word; eight bytes creates six words, plus one checksum word; and so on. The "seeds" created by this method will always be valid scalars as they are sent to sc_reduce32 first. The Private View Key is derived by hashing the Private Spend Key with Keccak-256, producing a second 256-bit integer, which is then sent to sc_reduce32. You can test out this style above by pressing the "Random" button on the upper right, or by pressing either of the "Random" buttons next to fields 1. and 2., then the various "Gen x." buttons. You can backup accounts of this type by writing down or otherwise saving the 25 word deterministic seed; you can easily restore using both Simplewallet and MyMonero.
  3. MyMonero Style – This is similar to 2., but uses a 13 word seed instead of a 25 word seed. The 13 words convert to a 128-bit integer that is used for both spend and view key derivation, in the following form: the 128-bit integer is hashed with Keccak-256 to produce a 256-bit integer, a. a is sent to sc_reduce32, which returns the Private Spend Key. a is hashed once more with Keccak-256 to produce a second 256-bit integer, b. b is then sent to sc_reduce32, which returns the Private View Key. You may have noticed a critical difference between this style and the Electrum Style: MyMonero's Private View Key derivation is done by hashing random integer a, while Electrum Style derivation is done by hashing the Private Spend Key. This means that 13 and 25 word seeds are not compatible – it is not possible to create an Electrum Style seed (and account) that matches a MyMonero Style seed (and account) or vice versa; the view keypair will always be different. You can test out this style above with the "Random MyMonero" button. To backup MyMonero accounts, save the 13 word seed; you can currently "restore" using MyMonero only (you're really just logging in) – Simplewallet does not currently support 13-word seeds.

Also, inspecting that site's code will tell you a great deal about how it all works, if you understand JavaScript. For example, if we're interested in how exactly is the checksum derived, we must look at the code as the process is not explained on the site.

The relevant functions for conversions between seed and mnemonic are in the mnemonic.js file. If you're generating the seed by some other means, all you really need to do is compute the checksum to end up with a valid mnemonic.

function mn_get_checksum_index(words, prefix_len) {
    var trimmed_words = "";
    for (var i = 0; i < words.length; i++) {
        trimmed_words += words[i].slice(0, prefix_len);
    }
    var checksum = crc32.run(trimmed_words);
    var index = checksum % words.length;
    return index;
}

What that function does is: assemble a string of prefixes of each of your 24 words, run a CRC32 on that string and use the resulting number to pick a checksum word. The word is picked from one of the words found in your mnemonic.

For example, if we have the mnemonic:

skirting trash phase buckets apology gags sedan coffee vinegar else fifteen pitched idled gorilla siren cucumber urban junk vastness laboratory rift rhino situated taxi

The string which we feed to CRC32 will be:

skitraphabucapogagsedcofvinelsfifpitidlgorsircucurbjunvaslabrifrhisittax

and the result of CRC32 performed on it will be 1790087523.

Performing a mod on that number with the number of words in your checksummed data (24 in this case) will give you an index of the checksum word:

3.

So, the checksum is the 4th (note that index is 0-based) word of your mnemonic:

buckets.

Does one need to have the dictionary of the mnemonic to be able to recover the wallet?

Yes. The mnemonic can be thought of as a list of 24 numbers between 0 and 1625, where the word is just a label for the number. Without knowing which word corresponds to which number, it would be impossible to reconstruct the correct wallet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.