0

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.

  • 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 May 1 '18 at 12:43
  • 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 May 1 '18 at 19:18
  • @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 Aug 17 at 14:19
0

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

#2 C++ - based

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? 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.

| improve this answer | |
  • 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 May 1 '18 at 19:48
  • 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 May 1 '18 at 19:51
  • 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 May 1 '18 at 20:22
  • Oh I got it. Thanks. How exactly is it used for error checking? Is it like a checksum? – Naz May 1 '18 at 20:23
  • % 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 May 1 '18 at 20:27
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 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 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). 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.

| improve this answer | |

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.