<p>Here are two mechanisms for converting a 256-bit (64 hexadecimal  characters) seed into a Electrum seed word mnemonics, and back again.</p>

<p><a href="https://xmr.llcoins.net/" rel="nofollow noreferrer"><strong>#1 JavaScript-based</strong></a></p>

<p><a href="https://github.com/skaht/XMR" rel="nofollow noreferrer"><strong>#2 C++ - based</strong></a></p>

<p>However, the command line interface example below, using mechanism #2, uses one of the most unsafe private seeds is used for demonstrative reference purposes only.</p>

<p>1% <strong>echo -n "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | ./bytes_to_words</strong></p>

<p><code>rover akin begun nifty laboratory point injury upper eldest enjoy gotten suffice batch snake hospital veteran eagle weird sieve podcast mighty oozed bimonthly biggest upper</code></p>

<p>2% <strong>echo "rover akin begun nifty laboratory point injury upper eldest enjoy gotten suffice batch snake hospital veteran eagle weird sieve podcast mighty oozed bimonthly biggest upper" | ./inverse_mnemonics</strong></p>

<p><code>0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff</code></p>

<p>The results are repeatable using mechanism #1. </p>

<p>BIP 39 doesn't require invertability support (analogous to ./inverse_mnemonics for Electrum words) albeit it can be accomplished. See <a href="https://bitcoin.stackexchange.com/questions/68605/how-to-generate-a-valid-hash-for-a-bip39-seed-phrase/75314#75314">How to generate a valid hash for a bip39 seed phrase?</a> for an approach for accomplishing this task. </p>

<p>The mapping back to the BIP 39 root seed in hex is guaranteed to be unique. However, due to normalization associated with ed25519 cryptography, not currently used by Bitcoin, it is possible to have multiple two sets of 25 Electrum words that map to the same functional private key. </p>

CC BY-SA 3.0
2018-05-01T19:48:37.090Z
What do you mean by unsafe private seeds? I have implemented my own method today. Similar to bip39. Split the byte buffer into equal size bit chunks and then use them as indices for words.
naz
CC BY-SA 3.0
2018-05-01T19:51:09.717Z
I have about the same number of combinations of words as in bip39 between level with 24 words and whatever is before 24 (21 words?)
naz
CC BY-SA 3.0
2018-05-01T20:22:06.067Z
The key **0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff** has very little entropy and can be easily guessed and used by a bot. The Electrum example provided uses 25 words. The 25th Electrum word is always a repeat of the other 24 words and is used for error checking purposes.
skaht
CC BY-SA 3.0
2018-05-01T20:23:58.753Z
Oh I got it. Thanks. How exactly is it used for error checking? Is it like a checksum?
naz
CC BY-SA 3.0
2018-05-01T20:27:42.200Z
% **echo -n 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff | bx mnemonic-new**

```abandon above dust dust case often baby melt fever creek oven upper mass error grit fetch roof taxi creek roof ten jazz zoo unique```
skaht
CC BY-SA 3.0
2018-05-01T20:32:47.087Z
The BIP 39 example just provided is essentially not invertible. Each 32-bits of hexadecimal numbers maps to three BIP 39 words. I believe but am not sure how the 25th Electrum word provides checksum services.
skaht
CC BY-SA 4.0
2018-06-07T03:27:18.593Z
See How to generate a valid hash for a bip39 seed phrase? and https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#generating-the-mnemonic for how the last BIP 39 word impacts error checking.
skaht
CC BY-SA 4.0
2018-08-17T07:01:07.950Z
that's not a valid electrum seed
Abdussamad
CC BY-SA 4.0
2018-05-01T19:46:21.007Z
2018-06-07T03:22:49.223Z
2018-06-07T03:22:49.223Z
skaht
<p><em>Short answer is yes but you shouldn't, see point 1 below, and long answer is no its not safe or advisable.</em></p>
<p>I would say what you are proposing which is akin to a brain-wallet style single private/public key pair in this question is inadvisable for a few reasons:</p>
<p><strong>1) The biggest risk</strong> is a lack of return change address (due to the absence of BIP32) in the case of sending anything less than the full balance will result in 100% loss of the difference (see <a href="https://bitzuma.com/posts/five-ways-to-lose-money-with-bitcoin-change-addresses/" rel="nofollow noreferrer">here</a> for more )</p>
<p><strong>2) because of the checksum used in BIP39</strong> which would alter your pasted binary data (i.e. pasting 256 bits for 24 words will later give you back 264 bits because of the 8-bit checksum that is appended to the last 11-bit group).</p>
<p><strong>2) Besides Electrum, most wallets only allow the importing of mnemonic recovery phrases</strong> that are BIP39 checksum compliant and won't allow you to use an elliptic curve private key. In my opinion, it is better to have a checksum compliant mnemonic, despite its security being 256 bits, or 8 bits lower than 264-bit mnemonic with no valid checksum. Because it is more widely usable across wallet, in case electrum goes down or no longer works/supported, etc...</p>
<p><strong>3) Decoding risks:</strong> if you are using a software that generates the private key in Base58 format, there is potential payload/checksum data attached that will increase the risk for errors when converting back to hex manually. Otherwise, if your are obtaining the private key in hex format, and are absolutely sure that it is the correct one in terms of the elliptical curve calculation to derive the public key and subsequent bitcoin formatted address, you can backup that string of hex characters in a number of ways.</p>
<p><strong>Still, it would be better to back up the entire bip 39 Mnemonic crypto vault</strong> and then use an offline tool to access any related needed private key such as <a href="https://iancoleman.io/bip39/" rel="nofollow noreferrer">Ian Coleman's BIP39 tool</a> offline (note: I am a contributor to that Github repo). Although you will still have to deal with converting Base58 encoded private keys, which I don't reccomend unless you know 100% how to do so without error.</p>
<p><strong>4) Error checking</strong>: not all 256-bit numbers are valid private keys, as per the Elliptic Curve specifications used in Bitcoin (here is a <a href="https://ethereum.stackexchange.com/questions/3542/how-are-ethereum-addresses-generated/74128#74128">related applicable post</a>). So there must be error checking if you are generating the private key yourself manually, to make sure the key is smaller than the maximum permitted value <code>0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141</code>.</p>
<p><strong>5)Regarding potential collision of private keys with mnemonics:</strong> yes there such collision, and it would be equal to two people randomly choosing or guessing the same private key (i.e., if the initial entropy for a mnemonic is the same entropy for an elliptic curve private key). Otherwise, the keyspace of private keys is the referenced above in point 4, and no two private keys point to the same address on the elliptic curve secp256k1 used in Bitcoin. The initial entropy range is 2^256 which is equal to the range of potential mnemonics 2048^24 minus the mnemonics with invalid checksums (otherwise the keyspace of mnemonics would be <code>2^264 ==2048^12</code> without the checksum requirement but both still wouldn't change the curve private keyspace ).</p>
<p>Again, I think it would be safer to follow the industry standard and use an HD wallet (which you would backup with a mnemonic).</p>
<p>P.S. You can further compress your backup using just the first 4 letters of each of the 24 words, provided that you are using the English BIP39 version, and concatentate them as a string of 44 characters. But when importing into a wallet, some don't autocomplete and you may have to lookup words manually from the list of 2048 BIP39 English words. I use an ecoding scheme that can further reduce the 44 charcters to 22 characters (including special symbols and numbers) with no information loss, but only to complement backups and not as a standalone replacement for BIP39 mnemonics.</p>

CC BY-SA 4.0
2020-08-17T14:15:44.603Z
2020-08-17T14:31:50.580Z
2020-08-17T14:31:50.580Z
Steven Hatzakis
<p>Is it safe to do the following?</p>

<p>Suppose I do not want the HD wallet, but I do want the convenience of using mnemonic words to remember the private key. I know I can convert the private key's hex representation to byte format from which I can get binary format, from there I can follow BIP-39 to generate 24 words that are represented by that private key (because general addresses are used by randomly producing a 256 bit word which is equivalent to 24 words). Can I now use these "mnemonic" words to remember my private key, and completely disregard it (since I can always use these words to get back to the private key). I guess what I am wondering is whether there are cases where different private keys can produce the same collection of 24 words.</p>

CC BY-SA 3.0
2018-05-01T12:43:53.043Z
actually the above wouldn't work. Because You won't get equal number of bit chunks if you use 11 bits like in BIP39.
naz
CC BY-SA 3.0
2018-05-01T19:18:31.433Z
Extended keys used by BIP 39 are 512 bits in length. Generally speaking, the path from BIP 39 words to private keys, especially when using detached keys, are not invertable.  This is unlike Electrum mnemonic seed words that are invertable. The Electrum mnemonic can represent 256 bits.
skaht
CC BY-SA 4.0
2020-08-17T14:19:51.927Z
@Naz correct, you would have to remember to discard the checksum when restoring the private key from the words, since the last word only carries 3 bits from the private key, whereas the last 8 bits are the checksum. I just provided further feedback in an answer, hope that helps.
Steven Hatzakis
<security><private-key><mnemonic-seed><bip>
Private key to mnemonic words, is it safe?
naz
# Private key to mnemonic words, is it safe?

(Asked by: username_0 on 2018-05-01)

Is it safe to do the following?

Suppose I do not want the HD wallet, but I do want the convenience of using mnemonic words to remember the private key. I know I can convert the private key's hex representation to byte format from which I can get binary format, from there I can follow BIP-39 to generate 24 words that are represented by that private key (because general addresses are used by randomly producing a 256 bit word which is equivalent to 24 words). Can I now use these "mnemonic" words to remember my private key, and completely disregard it (since I can always use these words to get back to the private key). I guess what I am wondering is whether there are cases where different private keys can produce the same collection of 24 words.

**Tags:** security, private-key, mnemonic-seed, bip

> **Comments:**
> **username_0**: actually the above wouldn't work. Because You won't get equal number of bit chunks if you use 11 bits like in BIP39.  
> **username_1**: Extended keys used by BIP 39 are 512 bits in length. Generally speaking, the path from BIP 39 words to private keys, especially when using detached keys, are not invertable.  This is unlike Electrum mnemonic seed words that are invertable. The Electrum mnemonic can represent 256 bits.  
> **username_2**: @Naz correct, you would have to remember to discard the checksum when restoring the private key from the words, since the last word only carries 3 bits from the private key, whereas the last 8 bits are the checksum. I just provided further feedback in an answer, hope that helps.  

---

## 2 answers

### Answer by username_1 on 2018-05-01. Score: 1

Here are two mechanisms for converting a 256-bit (64 hexadecimal characters) seed into a Electrum seed word mnemonics, and back again.

[**#1 JavaScript-based**](https://xmr.llcoins.net/)

[**#2 C++ - based**](https://github.com/username_1/XMR)

However, the command line interface example below, using mechanism #2, uses one of the most unsafe private seeds is used for demonstrative reference purposes only.

1% **echo -n "0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff" | ./bytes\_to\_words**

`rover akin begun nifty laboratory point injury upper eldest enjoy gotten suffice batch snake hospital veteran eagle weird sieve podcast mighty oozed bimonthly biggest upper`

2% **echo "rover akin begun nifty laboratory point injury upper eldest enjoy gotten suffice batch snake hospital veteran eagle weird sieve podcast mighty oozed bimonthly biggest upper" | ./inverse\_mnemonics**

`0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff`

The results are repeatable using mechanism #1.

BIP 39 doesn't require invertability support (analogous to ./inverse\_mnemonics for Electrum words) albeit it can be accomplished. See [How to generate a valid hash for a bip39 seed phrase?](https://bitcoin.stackexchange.com/questions/68605/how-to-generate-a-valid-hash-for-a-bip39-seed-phrase/75314#75314) for an approach for accomplishing this task.

The mapping back to the BIP 39 root seed in hex is guaranteed to be unique. However, due to normalization associated with ed25519 cryptography, not currently used by Bitcoin, it is possible to have multiple two sets of 25 Electrum words that map to the same functional private key.

> **Comments:**
> **username_0**: What do you mean by unsafe private seeds? I have implemented my own method today. Similar to bip39. Split the byte buffer into equal size bit chunks and then use them as indices for words.  
> **username_0**: I have about the same number of combinations of words as in bip39 between level with 24 words and whatever is before 24 (21 words?)  
> **username_1**: The key **0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff** has very little entropy and can be easily guessed and used by a bot. The Electrum example provided uses 25 words. The 25th Electrum word is always a repeat of the other 24 words and is used for error checking purposes.  
> **username_0**: Oh I got it. Thanks. How exactly is it used for error checking? Is it like a checksum?  
> **username_1**: % **echo -n 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff | bx mnemonic-new**  ```abandon above dust dust case often baby melt fever creek oven upper mass error grit fetch roof taxi creek roof ten jazz zoo unique```  
> **username_1**: The BIP 39 example just provided is essentially not invertible. Each 32-bits of hexadecimal numbers maps to three BIP 39 words. I believe but am not sure how the 25th Electrum word provides checksum services.  
> **username_1**: See How to generate a valid hash for a bip39 seed phrase? and https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki#generating-the-mnemonic for how the last BIP 39 word impacts error checking.  
> **username_3**: that's not a valid electrum seed  

---

### Answer by username_2 on 2020-08-17. Score: 0

*Short answer is yes but you shouldn't, see point 1 below, and long answer is no its not safe or advisable.*

I would say what you are proposing which is akin to a brain-wallet style single private/public key pair in this question is inadvisable for a few reasons:

**1) The biggest risk** is a lack of return change address (due to the absence of BIP32) in the case of sending anything less than the full balance will result in 100% loss of the difference (see [here](https://bitzuma.com/posts/five-ways-to-lose-money-with-bitcoin-change-addresses/) for more )

**2) because of the checksum used in BIP39** which would alter your pasted binary data (i.e. pasting 256 bits for 24 words will later give you back 264 bits because of the 8-bit checksum that is appended to the last 11-bit group).

**2) Besides Electrum, most wallets only allow the importing of mnemonic recovery phrases** that are BIP39 checksum compliant and won't allow you to use an elliptic curve private key. In my opinion, it is better to have a checksum compliant mnemonic, despite its security being 256 bits, or 8 bits lower than 264-bit mnemonic with no valid checksum. Because it is more widely usable across wallet, in case electrum goes down or no longer works/supported, etc...

**3) Decoding risks:** if you are using a software that generates the private key in Base58 format, there is potential payload/checksum data attached that will increase the risk for errors when converting back to hex manually. Otherwise, if your are obtaining the private key in hex format, and are absolutely sure that it is the correct one in terms of the elliptical curve calculation to derive the public key and subsequent bitcoin formatted address, you can backup that string of hex characters in a number of ways.

**Still, it would be better to back up the entire bip 39 Mnemonic crypto vault** and then use an offline tool to access any related needed private key such as [Ian Coleman's BIP39 tool](https://iancoleman.io/bip39/) offline (note: I am a contributor to that Github repo). Although you will still have to deal with converting Base58 encoded private keys, which I don't reccomend unless you know 100% how to do so without error.

**4) Error checking**: not all 256-bit numbers are valid private keys, as per the Elliptic Curve specifications used in Bitcoin (here is a [related applicable post](https://ethereum.stackexchange.com/questions/3542/how-are-ethereum-addresses-generated/74128#74128)). So there must be error checking if you are generating the private key yourself manually, to make sure the key is smaller than the maximum permitted value `0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141`.

**5)Regarding potential collision of private keys with mnemonics:** yes there such collision, and it would be equal to two people randomly choosing or guessing the same private key (i.e., if the initial entropy for a mnemonic is the same entropy for an elliptic curve private key). Otherwise, the keyspace of private keys is the referenced above in point 4, and no two private keys point to the same address on the elliptic curve secp256k1 used in Bitcoin. The initial entropy range is 2^256 which is equal to the range of potential mnemonics 2048^24 minus the mnemonics with invalid checksums (otherwise the keyspace of mnemonics would be `2^264 ==2048^12` without the checksum requirement but both still wouldn't change the curve private keyspace ).

Again, I think it would be safer to follow the industry standard and use an HD wallet (which you would backup with a mnemonic).

P.S. You can further compress your backup using just the first 4 letters of each of the 24 words, provided that you are using the English BIP39 version, and concatentate them as a string of 44 characters. But when importing into a wallet, some don't autocomplete and you may have to lookup words manually from the list of 2048 BIP39 English words. I use an ecoding scheme that can further reduce the 44 charcters to 22 characters (including special symbols and numbers) with no information loss, but only to complement backups and not as a standalone replacement for BIP39 mnemonics.


---

