To answer if it will be converted is really opinion-based as I'm not aware of anybody working on it.
To answer if there's an actual need is a harder one, but let's try.
Trezor support is on the way, despite Monero being a deviant child and daring to go its own way. If there's a real need for a BIP-39 variant, it will be done by whomever finds it important enough to do it. It's an open-source project after all so no permission is needed to come up with a scheme which would enable Monero wallet generation from the same word-list as used by Bitcoin. There shouldn't be any obstructions for adding such an option to the current wallet software, if someone was to code it and make a pull request.
But, let's consider few things. Just because something has a BIP number, and is presented in a clear and concise way, doesn't mean it's a standard, or a good solution for that matter. See also here for some considerations.
Current scheme used by Monero has some neat features which may be seen as advantageous over BIP-39:
- It's fairly simple and is a reversible conversion between any integer and a mnemonic. This means you can also find the mnemonic from your seed, even if your seed was generated by other means. BIP-39 uses hashing, so there's no way back - you can't work out the mnemonic from the seed.
- The above enables having different dictionaries / languages all encoding the same seed and you can freely transform from one to the other. I could even make my custom secret dictionary and use it without telling anybody, so nobody would even know what my mnemonic is actually used for. As long as I don't lose the dictionary myself, I'm safe.
- The scheme uses a wordlist prefix where every word has a unique first n letters. This allows for some optimizations. For example the dictionary storage requirement of some software used just to restore a seed could be reduced. It also allows users to mistype the remaining letters or even use alternative words which have the same first n letters.
Yes, you'd have to keep the dictionary around otherwise you lose the way to recover the seed. I'd argue you always need to keep something, even if it's a piece of software or a print-out of BIP-39 paper. What if in 10 years you can't google BIP-39, or the dictionary used in 2016?
Considering the above, what would be the advantage of moving to BIP-39 scheme? Which problem would it solve? Adding support is a non-issue, but why would one want to replace the current scheme by BIP-39? Chances are that it hasn't been adapted by Monero simply because there's no apparent benefit to it. To do anything, there needs to be a motivation. So, before talking about implementing it, one would have to ask first the question - which is the benefit? There are no standards in this space, and just because someone came up with a scheme which gained some traction doesn't make it a standard which everyone needs to follow.
If by convert you meant: take the Monero wallet, and generate a BIP-39 mnemonic from it - it's practically impossible. This is because BIP-39 is a one-way function, as mentioned above.
Let's consider the purpose of BIP-39,
It consists of two parts: generating the mnemonic, and converting it
into a binary seed. This seed can be later used to generate
deterministic wallets using BIP-0032 or similar methods.
and how it works.
To create a binary seed from the mnemonic, we use the PBKDF2 function
with a mnemonic sentence (in UTF-8 NFKD) used as the password and the
string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt.
The iteration count is set to 2048 and HMAC-SHA512 is used as the
pseudo-random function. The length of the derived key is 512 bits (=
So, we have a way of going from "anything" to 512 bits. In Bitcoin, these are used to further derive address keypairs using some HD scheme, like BIP-32, which uses secp256k1 curve to derive the keypairs, so for sure there would have to be some major changes done to it to be able to generate Monero keypairs.
Now, if we want to go from 512 bits to a Monero wallet, what are the options?
- You could use the first 256 bits as the private spend key and 2nd 256 bits as the private view key. This would make the 2 keys independent, so it would break compatibility with Monero seed scheme.
- You could use the first 256 bits (or hash the 512 bits to 256 bits) as the monero seed, and go from there. This would let you keep the compatibility with the current Monero scheme as you could also generate a Monero mnemonic from it, if you would want to do so.
- Something else.
On another note, Monero doesn't really need HD wallets, as there is no problem it would be fixing, unlike with Bitcoin where you're supposed to use a different address each time. There's a saying: "To a hammer, everything looks like a nail." For some cases there could be an use, but then the above point of being open-source would apply again.