Is it possible to convert WIF to seed phrases (BIP39)?

[Saint-loup]

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

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.

[1715225709]

1715225709

[1715225709]

1715225709

[1715225709]

1715225709

[alexeyneu]

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.

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

[Saint-loup]

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.

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

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.

Code:

>bx base58check-decode 5JphUWRuWJwZktUdGBUmtsazoc1GGuRXFBxoTkJWZGpXjUzXXa7
wrapper
{
    checksum 1484882920
    payload 84a1a9c49c1257de2d4ff2eec4f6cf109e6be3df6e075efb9ad895efeab20201
    version 128
}

>bx base58check-encode -v128 84a1a9c49c1257de2d4ff2eec4f6cf109e6be3df6e075efb9ad895efeab20201
5JphUWRuWJwZktUdGBUmtsazoc1GGuRXFBxoTkJWZGpXjUzXXa7

[alexeyneu]

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

Code:

	unsigned char tr_e = 0;
...
        BN_bn2bin(balance_eth_remmi_e, &tr_e);

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

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.

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

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.

Code:

>bx base58check-decode 5JphUWRuWJwZktUdGBUmtsazoc1GGuRXFBxoTkJWZGpXjUzXXa7
wrapper
{
    checksum 1484882920
    payload 84a1a9c49c1257de2d4ff2eec4f6cf109e6be3df6e075efb9ad895efeab20201
    version 128
}

>bx base58check-encode -v128 84a1a9c49c1257de2d4ff2eec4f6cf109e6be3df6e075efb9ad895efeab20201
5JphUWRuWJwZktUdGBUmtsazoc1GGuRXFBxoTkJWZGpXjUzXXa7

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

[Saint-loup]

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.

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 ?

[alexeyneu]

format here is not strict

[alexeyneu]

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