I've been messing around with Ian Coleman's Mnemonic Code Converter. It's a handy tool for turning BIP39 mnemonic phrases into addresses and private keys.
Check it out here: https://iancoleman.io/bip39/
There’s also a standalone offline version: https://github.com/iancoleman/bip39.
But I’m wondering, is it possible to work backwards and figure out a mnemonic from an extended private key? Like the extended key from a wallet made with Bitcoin Core?
Can you generate a mnemonic from an xprv?
6 replies 173 views
You cannot calculate or derive a mnemonic from an extended key or master private key (xprv) it is a one way hashing function that cant be reversed. The mnemonic of bip 39 are used to derive the Hierarchy deterministic (HD) seed and then an extended or master private key, and since the move from Mnemonic to HD seed is created using PBKDF2 then it can be reversed.
It is
Mnemonic - HD seed - master private key. The reversal is not possible
Just as it has been explained above, it is not possible. The mnemonic is converted to seed through PBKDF2 key stretching function with 2048 rounds of hashing using HMAC-SHA12. This is irreversible and it is an effective protection against brute force attack.
r3al_v4ultMember
Posts: 54 · Reputation: 222
#4Jul 1, 2019, 07:06 PM
If this is about finding an easy way to backup your Bitcoin Core wallet to a paper or metal plate,
it should be done the other way around (I've seen your thread about creating cold-storage Bitcoin Core):
Create a BIP39 mnemonic->Derive the Master Private Key->Manually create descriptors with it->Import to a blank wallet
But the obvious downside is you'll have to use a third-party to generate the entropy which could be using insecure RNG.
So try to find a safe open-source BIP39 tool/wallet that you can audit if you really have to use a mnemonic seed.
You can also just backup the master private key and your descriptors' various derivation paths if the whole descriptors are too long.
Thank you all for putting me on the right track once again. And also for the references to the specific algorithms.
Yes, it was a bit of a XY problem. I actually thought about creating a mnemonic from the master key, which I have now learned is impossible.
Exactly, that's why I don't want to do that. With what little knowledge I have, I prefer to handle things canonically (although I am only just learning what that actually means),
I will back up the wallet offline but digitally. Nevertheless, I would like a paper back-up in case of disaster. It should be sufficient to note the master key and the root of the path of the descriptor used (for example /84'/0'/0'/0/*), right?
The public part is stored in my watch only wallet (full node), which I use to create the unsigned transactions, which I then transfer to the cold wallet and sign there. That's how I've understood it so far.
I would point out that the PBKDF2 used in bitcoin actually provides very weak protection against brute force. 2,048 rounds is a very small number. Bitcoin Core uses a minimum of 25,000 rounds, but usually much more depending on the hardware of your machine. Many other algorithms will use hundreds of thousands or even millions of iterations. The protection of seed phrases against brute force attacks stems from the 2128 bits of entropy, not from the 2,048 rounds of hashing.
If you don't want to trust any piece of hardware or software to generate your entropy and seed phrase for you, then consider generating it manually by flipping a coin to generate a binary string and then mapping that to words on the word list. You'll only need to use an (airgapped!) computer in order to generate the checksum for the final word.
r3al_v4ultMember
Posts: 54 · Reputation: 222
#7Jul 2, 2019, 02:28 AM
Yes, since Bitcoin Core is using the standard BIP44, BIP84, BIP49 and BIP86 paths, the master private key should be enough as a backup.
However, you'll need at least a reminder on how to import the xprv which is the derivation paths of each descriptor to recreate them, other wallet compatibility or manual derivation.
You can't always trust your memory to distinctly remember what to do with the backup and we'll never know if the current standard will become depreciated in the future.
That's an option if the backup space is limited (e.g.: metal plate)
But if possible, backup the whole descriptors, all of them.