Topic: Is it possible to convert WIF to seed phrases (BIP39)? (Read 526 times)

about libcrypto.dll : you can google for poco openssl binaries

format here is not strict

Why did your project produce 27 words initially instead of 24? And now why it gives a normal 24 words length? What have you changed?
There is a checksum at the end of your 24 words mnemonic seed? There is one too in your 27 words one?
What do you mean precisely when you say "you can extract wif to 32-byte then base58 it on your own  and then supply latter to the tool"
You mean we have to use a base58 convertor and not a base58check one ?

bug is found and fixed.

it looks like openssl doesn't like one byte types when it goes as BE on LE machine and without padding(?). i made it two bytes long with LE and padding ( BN_bn2lebinpad ) it's gone. this was the bad one
i've added -wif24 option so it can be done bt the tool now. and if you used it for decompressor it should be used in compressor




idk what's bx . https://github.com/luke-jr/libbase58/pull/16/commits

What are you talking about precisely? Could you use a translator please, it's not the first time you talk to me about this function and last time you were already wrong despite your rude words  .

This is the result I get on my computer, is it wrong? It's the same one as JohanM above for the base58check to hexadecimal conversion and the same I get with this online tool.
And ofc the base58check-encode command give back the right WIF key from this value, as expected.

library mentioned is little-endian (hardcoded). so he needs not a number .
 Can't still find the cause of my

Thank you for this example step by step with a checksum. Well you are right, we can even add the BIP38 checksum if we want because it fits well the 24 words length (264/11). It would have been a good idea to also show a step by step example of a decoding process from a seed though. Since it's important for people to not forget to add padding with 0 in front of small binary numbers to fill the 11 digit string.

https://github.com/alexeyneu/base58_2048

msvc 2019 project with cmake build support.
in windows you should have libcrypto.dll next to .exe files, not included
wif key is 27 words. upd  24 w support added

if you really know what you're doing you can extract wif to 32-byte then base58 it on your own  and then supply latter to the tool. you'll have shorter phrase upd It's now there.

compressor: words delivered from file. file name provided via command line

dcompressor: base58 encoded thing provided via command line
for 18 bytes block it will be 14 words

With 12 words you can only encode 16 bytes (128 bits). For 32 bytes you need 24 words. The word list contains 2048 words so 11 bits.

well i see enough demand for this to make it. we need a standard for 32 bytes -> 12 words thing. So someone then can figure out how to recover this stuff if tool is lost. i think to snoop it from monero, they support phrases from the start.

But better way is this: just to scale base58 lib which now does [0..255] ⇆ [0..57] to [0..2047] ⇆ [0..57]. So we'll have 32 bytes -> base58 of it -> words. it then could be applied to wif or whatever. amount will be not 12 ofc and not fixed
upd
number of words appear to be fixed either for wif or 32-byte  block. so it's straight transition

If you just want to backup a single WIF key using the word list, that is perfectly possible:

So let's take an example WIF key:
5JphUWRuWJwZktUdGBUmtsazoc1GGuRXFBxoTkJWZGpXjUzXXa7

We recalculate to the hex SEED using base58CheckDecode, this gives us the 32 bytes seed:
84A1A9C49C1257DE2D4FF2EEC4F6CF109E6BE3DF6E075EFB9AD895EFEAB20201

In binary this gives:
1000010010100001101010011100010010011100000100100101011111011110001011010100111 1111100101110111011000100111101101100111100010000100111100110101111100011110111 1101101110000001110101111011111011100110101101100010010101111011111110101010110 0100000001000000001

The SHA-256 checksum of this is:
45F4FD103DAAB39409C60F715E9A4B66D32322C7926ED2364169F232998D5808 or in binary
0100010111110100111111010001000000111101101010101011001110010100000010011100011 0000011110111000101011110100110100100101101100110110100110010001100100010110001 1110010010011011101101001000110110010000010110100111110010001100101001100110001 1010101100000001000

We take the first 8 bits of this hash to add at the end of the first binary bits:
So we add 01000101
and it becomes:
1000010010100001101010011100010010011100000100100101011111011110001011010100111 1111100101110111011000100111101101100111100010000100111100110101111100011110111 1101101110000001110101111011111011100110101101100010010101111011111110101010110 010000000100000000101000101
This is 264 bits length (which is divisible by 11 = 24 words)

Translating this to the BIP wordlist gives us:
lucky ask illness deal century upper release wrestle uphold chicken record cancel trade vehicle laundry science galaxy system renew cloth wrong flip amount chunk

This wordlist can be retranslated to the WIF at any time. It also contains an 8 bit checksum so you know. There is only a 0.4% chance that replacing one word will give you a correct checksum (1 in 256).

You should be able to do it thanks to Libbitcoin Explorer tool

In order to transform the WIF key into a phrase with BIP39 words (without checksum), you can do that this way :
First, thanks to Bx base58check-decode you can get the hexadecimal value of the key.

Now you will "just" need to convert this hexadecimal number into a binary one, and with your hands, to split it into groups of 11 bits, each encoding a number from 0-2047, serving as an index into a wordlist as BIP39 does and to find the word corresponding to the index(+1) into the BIP39 dictionary of the language of your choice.


For decyphering your seed you'll consecutively take the index(-1) from the dictionary of each word of your phrase, convert each decimal index into its 11bits binary value (with enough 0 for padding) , group the 11bits words into a whole binary number that will be converted into its hexadecimal value, and apply bx base58check-encode to this value to get back your WIF key.

Writing the code for such a tool is easy, the hard part is optimizing it and writing the code to run it on GPUs. As you said there isn't enough demand for such a tool so the effort and the time is better spent on something more useful.

The idea I used in this post is basically seeing a WIF as a 256-bit data that can be encoded any way you like, such as using the algorithm similar to what BIP-39 uses (split into 11-bit limbs and convert to words from a 2048-word long list). I used this tool by the way.

The point of doing this is not to be able to enter the mnemonic result into a wallet like Electrum. The point was to introducing a way to convert a hard to write down WIF (base-58 characters) into an easy to write down set of words with a checksum.
In order to be able to import it into any wallet, you have to do this in reverse first (mnemonic to entropy, entropy to WIF).

Doing this as you described is impossible nowadays, if there is a solution similar to what you want to do, it may be unsafe in the long term due to several factors: the generated seed may be useless as it does not follow the BIP39 standard, incompatibility or inconsistency, not being recognized by any wallet when restoring it.

One solution for you today is to use Bitcoin Core, create the wallet, import the WIF private key from your current vanity address and back up that file. Subsequent balances received at this address, if there is a difference, will be transferred to the change address of your Core wallet (currently Core is the only wallet that allows this). This way you back up your wallet from the wallet.dat file.

Then I suppose Base58 failed at accomplishing its very own purpose in some cases, being "human-friendly".
IDK but WIF private keys don't look intimidating to copy for me since each characters look different from each other.

Based from OP's latest reply, I guess this is a matter of preference rather than actual (dis)advantage when it comes to writing backups.

Technically you can "stretch" the private key bytes of the vanity address into seed phrase bytes, minus the entropy of course, and then convert that to a mnemonic phrase. In doing so you will generate a new set of private keys and addresses. But if the method gets found out then there is no security in doing so obviously.


I don't think so. It is very hard to coordinate public addresses at any given derivation path to use the same address prefix or range.

I don't think there is or will ever be enough demand to motivate someone to create such a tool, it will stay on a hobby level. Can you create such a tool by the way?

When I google, I only see mnemonic to WIF converters, not WIF to mnemonic.

I checked threads that you guys linked here.  As far as I understand, it's possible to convert WIF to mnemonic but it's impossible to import them in Electrum or other wallet but why? If it's not possible, then there is no point in converting WIF to mnemonic as I understand.

It's not as long but there is a very unusual combination of big and small characters and numbers. Words, while being longer, are still a better choice to my mind.