Return to Answer

TL;DR first is completely random seed, 2nd is the "normalized" seed, and they're both valid and resolve to the same wallet. As long as you know the method to go from mnemonic to the actual private key, you're safe to keep it as it is.

The first is a just some random 256 bits, probably generated by other means and the second is the "normalized" seed, meaning it's a number smaller than l (a parameter specific to the elliptic curve used in monero cryptography scheme). Both seeds resolve to the same private spend key and are equally valid. The private spend key is the important piece of data which is used on the protocol level. You could even use your own, custom, mnemonic scheme to get from mnemonic/seed to private spend key. The protocol doesn't care about the mnemonic/seed, only about the 4 keys (spend keypair and view keypair)

If you restore the wallet with the first seed, and after restoring use the "seed" command, the wallet will print the second seed. This is because it automatically normalizes the seed. Let me elaborate.

First of all, your mnemonic is a representation of a 256 bit integer, ie a very very big number. This number is your seed, and from it the keys are derived and those are actually used in cryptography on the protocol level. There is a function which converts between the number (seed) and the mnemonic. How the conversion works, is explained here.

To get the private spend key, the seed is passed through sc_reduce32 function:

privSpend = sc_reduce32(seed)

if the seed is a random 256bit integer, then it can happen that:

seed != sc_reduce32(seed)

however, if your seed has already been passed through sc_reduce32 function, then it's what we call a "normalized seed" and both the seed and privSpend will be the same, i.e. passing a normalized seed through sc_reduce32 results in the exact same number.

n_seed = privSpend = sc_reduce32(seed)
n_seed == sc_reduce32(n_seed)

Since n_seed != seed, the mnemonic corresponding to each of them will also be different.

You could easily produce the normalized seed yourself, by playing with this page:

1. Type in your first seed into box 1.
2. Click "Gen 2." and "Gen 3. & 4.", notice that 2. & 3. are different.
3. Copy the value from box 3. into box 2.
4. Click "Gen 1." and "Gen 3. & 4.", you will notice 3. and 4. didn't change and 2. & 3. are now the same.

TL;DR first is completely random seed, 2nd is the "normalized" seed, and they're both valid and resolve to the same wallet. As long as you know the method to go from mnemonic to the actual private key, you're safe to keep it as it is.

The first is a just some random 256 bits, probably generated by other means and the second is the "normalized" seed, meaning it's a number smaller than l (a parameter specific to the elliptic curve used in monero cryptography scheme). Both seeds resolve to the same private spend key and are equally valid. The private spend key is the important piece of data which is used on the protocol level. You could even use your own, custom, mnemonic scheme to get from mnemonic/seed to private spend key. The protocol doesn't care about the mnemonic/seed, only about the 4 keys (spend keypair and view keypair)

If you restore the wallet with the first seed, and after restoring use the "seed" command, the wallet will print the second seed. This is because it automatically normalizes the seed. Let me elaborate.

First of all, your mnemonic is a representation of a 256 bit integer, ie a very very big number. This number is your seed, and from it the keys are derived and those are actually used in cryptography on the protocol level. There is a function which converts between the number (seed) and the mnemonic. How the conversion works, is explained here.

To get the private spend key, the seed is passed through sc_reduce32 function:

privSpend = sc_reduce32(seed)

if the seed is a random 256bit integer, then it can happen that:

seed != sc_reduce32(seed)

however, if your seed has already been passed through sc_reduce32 function, then it's what we call a "normalized seed" and both the seed and privSpend will be the same, i.e. passing a normalized seed through sc_reduce32 results in the exact same number.

n_seed = privSpend = sc_reduce32(seed)
n_seed == sc_reduce32(n_seed)

Since n_seed != seed, the mnemonic corresponding to each of them will also be different.

You could easily produce the normalized seed yourself, by playing with this page:

1. Type in your first seed into box 1.
2. Click "Gen 2." and "Gen 3. & 4.", notice that 2. & 3. are different.
3. Copy the value from box 3. into box 2.
4. Click "Gen 1." and "Gen 3. & 4.", you will notice 3. and 4. didn't change and 2. & 3. are now the same.

TL;DR first is completely random seed, 2nd is the "normalized" seed, and they're both valid and resolve to the same wallet. As long as you know the method to go from mnemonic to the actual private key, you're safe to keep it as it is.

The first is a just some random 256 bits, probably generated by other means and the second is the "normalized" seed, meaning it's a point on the elliptic curve used by monero for public key cryptography. Both seeds resolve to the same private spend key and are equally valid. The private spend key is the important piece of data which is used on the protocol level. You could even use your own, custom, mnemonic scheme to get from mnemonic/seed to private spend key. The protocol doesn't care about the mnemonic/seed, only about the 4 keys (spend keypair and view keypair)

If you restore the wallet with the first seed, and after restoring use the "seed" command, the wallet will print the second seed. This is because it automatically normalizes the seed. Let me elaborate.

First of all, your mnemonic is a representation of a 256 bit integer, ie a very very big number. This number is your seed, and from it the keys are derived and those are actually used in cryptography on the protocol level. There is a function which converts between the number (seed) and the mnemonic. How the conversion works, is explained here.

To get the private spend key, the seed is passed through sc_reduce32 function:

privSpend = sc_reduce32(seed)

if the seed is a random 256bit integer, then it can happen that:

seed != sc_reduce32(seed)

however, if your seed has already been passed through sc_reduce32 function, then it's what we call a "normalized seed" and both the seed and privSpend will be the same, i.e. passing a normalized seed through sc_reduce32 results in the exact same number.

n_seed = privSpend = sc_reduce32(seed)
n_seed == sc_reduce32(n_seed)

Since n_seed != seed, the mnemonic corresponding to each of them will also be different.

You could easily produce the normalized seed yourself, by playing with this page:

1. Type in your first seed into box 1.
2. Click "Gen 2." and "Gen 3. & 4.", notice that 2. & 3. are different.
3. Copy the value from box 3. into box 2.
4. Click "Gen 1." and "Gen 3. & 4.", you will notice 3. and 4. didn't change and 2. & 3. are now the same.

TL;DR first is completely random seed, 2nd is the "normalized" seed, and they're both valid and resolve to the same wallet. As long as you know the method to go from mnemonic to the actual private key, you're safe to keep it as it is.

The first is a just some random 256 bits, probably generated by other means and the second is the "normalized" seed, meaning it's a number smaller than l (a parameter specific to the elliptic curve used in monero cryptography scheme). Both seeds resolve to the same private spend key and are equally valid. The private spend key is the important piece of data which is used on the protocol level. You could even use your own, custom, mnemonic scheme to get from mnemonic/seed to private spend key. The protocol doesn't care about the mnemonic/seed, only about the 4 keys (spend keypair and view keypair)

If you restore the wallet with the first seed, and after restoring use the "seed" command, the wallet will print the second seed. This is because it automatically normalizes the seed. Let me elaborate.

First of all, your mnemonic is a representation of a 256 bit integer, ie a very very big number. This number is your seed, and from it the keys are derived and those are actually used in cryptography on the protocol level. There is a function which converts between the number (seed) and the mnemonic. How the conversion works, is explained here.

To get the private spend key, the seed is passed through sc_reduce32 function:

privSpend = sc_reduce32(seed)

if the seed is a random 256bit integer, then it can happen that:

seed != sc_reduce32(seed)

however, if your seed has already been passed through sc_reduce32 function, then it's what we call a "normalized seed" and both the seed and privSpend will be the same, i.e. passing a normalized seed through sc_reduce32 results in the exact same number.

n_seed = privSpend = sc_reduce32(seed)
n_seed == sc_reduce32(n_seed)

Since n_seed != seed, the mnemonic corresponding to each of them will also be different.

You could easily produce the normalized seed yourself, by playing with this page:

1. Type in your first seed into box 1.
2. Click "Gen 2." and "Gen 3. & 4.", notice that 2. & 3. are different.
3. Copy the value from box 3. into box 2.
4. Click "Gen 1." and "Gen 3. & 4.", you will notice 3. and 4. didn't change and 2. & 3. are now the same.

TL;DR first is completely random seed, 2nd is the "normalized" seed, and they're both valid and resolve to the same wallet. As long as you know the method to go from mnemonic to the actual private key, you're safe to keep it as it is.

The first is a just some random 256 bits, probably generated by other means and the second is the "normalized" seed, meaning it's a point on the elliptic curve used by monero for public key cryptography. Both seeds resolve to the same private spend key and are equally valid. The private spend key is the important piece of data which is used on the protocol level. You could even use your own, custom, mnemonic scheme to get from mnemonic/seed to private spend key. The protocol doesn't care about the mnemonic/seed, only about the 4 keys (spend keypair and view keypair)

If you restore the wallet with the first seed, and after restoring use the "seed" command, the wallet will print the second seed. This is because it automatically normalizes the seed. Let me elaborate.

First of all, your mnemonic is a representation of a 256 bit integer, ie a very very big number. This number is your seed, and from it the keys are derived and those are actually used in cryptography on the protocol level. There is a function which converts between the number (seed) and the mnemonic. How the conversion works, is explained here.

To get the private spend key, the seed is passed through sc_reduce32 function:

privSpend = sc_reduce32(seed)

if the seed is a random 256bit integer, then it can happen that:

seed != sc_reduce32(seed)

however, if your seed has already been passed through sc_reduce32 function, then it's what we call a "normalized seed" and both the seed and privSpend will be the same, i.e. passing a normalized seed through sc_reduce32 results in the exact same nubmber.

n_seed = privSpend = sc_reduce32(seed)
n_seed == sc_reduce32(n_seed)

Since n_seed != seed, the mnemonic corresponding to each of them will also be different.

You could produce the normalized seed yourself, by playing with this page:

1. Type in your first seed into box 1.
2. Click "Gen 2." and "Gen 3. & 4.", notice that 2. & 3. are different.
3. Copy the value from box 3. into box 2.
4. Click "Gen 1." and "Gen 3. & 4.", you will notice 3. and 4. didn't change and 2. & 3. are now the same.

TL;DR first is completely random seed, 2nd is the "normalized" seed, and they're both valid and resolve to the same wallet. As long as you know the method to go from mnemonic to the actual private key, you're safe to keep it as it is.

The first is a just some random 256 bits, probably generated by other means and the second is the "normalized" seed, meaning it's a point on the elliptic curve used by monero for public key cryptography. Both seeds resolve to the same private spend key and are equally valid. The private spend key is the important piece of data which is used on the protocol level. You could even use your own, custom, mnemonic scheme to get from mnemonic/seed to private spend key. The protocol doesn't care about the mnemonic/seed, only about the 4 keys (spend keypair and view keypair)

If you restore the wallet with the first seed, and after restoring use the "seed" command, the wallet will print the second seed. This is because it automatically normalizes the seed. Let me elaborate.

First of all, your mnemonic is a representation of a 256 bit integer, ie a very very big number. This number is your seed, and from it the keys are derived and those are actually used in cryptography on the protocol level. There is a function which converts between the number (seed) and the mnemonic. How the conversion works, is explained here.

To get the private spend key, the seed is passed through sc_reduce32 function:

privSpend = sc_reduce32(seed)

if the seed is a random 256bit integer, then it can happen that:

seed != sc_reduce32(seed)

however, if your seed has already been passed through sc_reduce32 function, then it's what we call a "normalized seed" and both the seed and privSpend will be the same, i.e. passing a normalized seed through sc_reduce32 results in the exact same number.

n_seed = privSpend = sc_reduce32(seed)
n_seed == sc_reduce32(n_seed)

Since n_seed != seed, the mnemonic corresponding to each of them will also be different.

You could easily produce the normalized seed yourself, by playing with this page:

1. Type in your first seed into box 1.
2. Click "Gen 2." and "Gen 3. & 4.", notice that 2. & 3. are different.
3. Copy the value from box 3. into box 2.
4. Click "Gen 1." and "Gen 3. & 4.", you will notice 3. and 4. didn't change and 2. & 3. are now the same.