Will Monero mnemonic seeds need to be converted to BIP 39 for standardization reasons?

Question

According to this answer it was suggested that Monero will likely eventually need convert Electrum Wallet compliant mnemonic seeds to BIP 39 compliant mnemonic seeds for compatibility/integration reasons.

Are there any currently efforts to replicate this wallet generation standard in a BIP 39 standard?

Have there been any payment processors, merchants, or hardware wallet companies that are known to have requested this change in order to ease Monero integration?

Answer 1

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 (= 64 bytes).

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?

1. 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.
2. 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.
3. 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.

Answer 2

Technical testing discussions with functional experimental code and concerning this matter are posted here. NoodleDoodle is definitely pushing the state of the art of Monero for BIP 39 support with tight Trezor integration.

However, the current issue is the Trezor V0313 binary implementation of trezorctl on a Mac can't create Electrum seed words from BIP 39 seed words when there is a rubber-hose password (plausible deniability exists), see Experimental trezor firmware testing for a recent posting concerning this matter.

The 4th posting provides working examples as to how BIP 32/39/44 technology can be applied to translate between BIP 39 seed words and Electrum words with a "rubber-hose" password (e.g., "1234"). The test vector examples, starts with a brain wallet, uses a combination of libbitcoin (bx) code and Monero code. Bitcoin Explorer (bx) commands faithfully reproduces BIP 44 keys and addresses from BIP 39 seeds that Trezor Web Application, Jaxx, including numerous altcoins.

NoodleDoodle desires not to apply BIP 44 paths. However, I can't yet independently reproduce NoodleDoodle's m/1'/2'/3'/4'/n' path results for (spend key and Monero stealth address) he claimed the V0313 trezorctl implements - when I apply bx, and a homegrown version of ./xmr built upon Monero foundations that matches results from Cryptonote Address Test.

An Exodus developer is leaning towards the application of BIP 47 instead of BIP 44. I'll provide a posting for a potential BIP 47 path ( e.g., m/47'/128’/(identity' or n’)' where a hardened n = 0 through 2147483647 ) for four Monero test vectors, with and without a rubber-hose password for n' = 0 and 255. Wallet end users should only need to record one set of seed words to reconstitute their multi-currency wallets, not two or more. Harmonization between Electrum seed words and BIP 39 seed words is sorely needed.

Electrum seed words afford portability of Monero wallets across Monero hard forks, e.g., migration from Hydrogen Helix to a mandatory Ring CT Monero network capability. It is possible to make BIP 39 and Electrum seeds co-exist with BIP 39 as the basis for key synthesis. Like it or not, BIP 39 has a much stronger foothold in the HD multi-currency hardware wallet vendors (e.g., Trezor, Keepkey, Ledger), and HD multi-currency GUI cryptocurrency wallet providers than Electrum seed words (that are yes invertible, unlike BIP 39).

Answer 3

Adding support is a non-issue, but why would one want to replace the current scheme by BIP-39?

The existing scheme is complicated and brittle. To turn a seed phrase into a key, you need a dictionary. Actually you need a whole set of language-specific dictionaries, since you don't know what language the seed will be in. Those dictionaries have changed in the past, for whatever reason, leaving people's seed phrases unusable. Certainly new languages will need to be added, creating a maintenance burden for every implementation.

As soon as there's more than one implementation, there will have to be a big negotiation every time a language is added or an existing dictionary is changed.

If you just hash the input, rather than trying to "decode" it, you make it possible for a user to use a phrase that's meaningful to them, making it much more feasible to memorize the seed for your wallet. That's especially valuable if your wallet is used mostly for a limited amount of "spending money", as opposed to a huge store of value.

[Now I'm going to go RTFM and find out why this didn't show up as a comment on the answer above and exactly how one IS supposed to respond at length to an answer... if at all. Sorry.]