Extended mnemonic codes #602
Conversation
|
It would be nice if comprehension of this EIP didn't require familiarity with one or more associated BIPs. |
|
I could inline the contents of the Mnemonic BIP here, but I figured it was widely used, and inlining it would require anyone already familiar with it to reread it to make sure it was the same. What do others think? |
|
On further thought, I've rewritten the EIP to incorporate BIP39 so it stands alone, as @gavofyork suggested. |
|
This proposal would make it much easier for clients to implement support for alternative HD path support, like in #600 and #601, as well as giving us a path forward when evolving the HD derivation path standard, so I'm in support of this. Without this, we would have to ask users what kind of mnemonic they're entering when restoring a vault, and hope the user knows the difference. Including a little metadata in the mnemonic is a clever solution going forward. |
|
|
||
| Several Ethereum wallets have adopted BIP39 mnemonics for use on the Ethereum platform, as have some other products such as paper wallets. As a rule, adopting BIP39 without changes works well, but there are two shortcomings: | ||
|
|
||
| - Confusion over derivation paths for the resulting HD wallets, as described in eip-draft-hdwallets. |
|
If we follow a new mnemonic standard then it will not be possible to back up all the user's coins (ether, bitcoin and other cryptocurrencies) under one single mnemonic code. Right now with BIP32, BIP44 and BIP39, it is possible to have just one single mnemonic that restores everything. Quite often when I see a new standard proposal, this comes to mind: https://xkcd.com/927/ The idea behind BIP32 is to have all your keys under one single root. Would it be possible to have ethers and bitcoins restored under one single mnemonic? |
It will be, so long as any multi-currency wallet also supports deriving keys for other cryptocurrencies from the new mnemonics. |
Unfortunately, this isn't quite true. To get to an address you need a mnemonic (BIP39) plus a derivation path (BIP32). This has lead to a significant amount of confusion for users because most wallets tell them, "Write down your mnemonic and you can restore it anywhere" but this isn't true. In reality the user needs to write down their mnemonic AND the derivation path in order to restore access to an address. The idea with this EIP along with #600 and #601 is to make it so users truly can store just a mnemonic and be able to regain access to their address. The ultimate goal of this is to improve the end-user experience and reduce the support burden on wallet authors. Almost all wallet authors I have spoken with have indicated that the support burden of the current mnemonic+derivation path is surprisingly high. |
Exactly.
That problem is already solved. The problem appears when ethereum wallets don't follow the BIP44 (with SLIP-0044) standard. Creating a yet another standard (#600 and #601) does not solve the problem of wallets not following the standards. I think extended mnemonic codes (#602) are great for creating multi-part mnemonics based on secret sharing schemes, and trustless encrypted paper wallets similar to those described in [BIP38]. But IMHO adding yet another standard for derivation paths (#600 and #601) just adds to the confusion and wallets will be even less compatible, not more. |
|
Regarding password protected extended mnemonics, I think all mnemonics should have the option to be password protected. Optional password protection provides better deniability in case the user is forced to give his/her mnemonic. If the user mnemonic is of the specific type "password protected extended mnemonics" it is quite clear that the user knows about password protecting their mnemonic. I know it is possible to have two passwords, one password brings you to a wallet with small amount of coins, the other password brings you to the real user's wallet with a large amount of coins. However having always the option to add a password to any mnemonic is very useful and makes more believable when the user claims that a specific mnemonic is not password protected. On top of that, users would like to password protect any future kind of extended mnemonic codes. |
BIP32 + BIP39 are not enough. All wallets must also follow BIP43 and some implementation of that (such as BIP44). On top of that when doing multi-address wallets different wallets may infringement different segments (e.g.,
If only that were true... 😄 #84 (comment)
As you can see in the above linked issue, because BIP44 was designed for Bitcoin, it isn't exactly clear how it should have been utilized in Ethereum. Also, due to the
I am of the opinion that the real problem here is the fact that there is no standard in Ethereum. Even the above linked issue was never resolved. If there was an accepted EIP that went through that would be a huge step up over the current situation. The goal with these issues is to simply pick something simple so we can hopefully get some EIPs all the way through the process. They provide an extensibility mechanism so if people want something more full-featured they can have it while also resolving the UX problems associated with the existing mechanisms. They are also Ethereum specific, which hopefully helps reduce contention in the Ethereum community of what the meaning of the various derivation path segments is. These EIPs are an attempt to simplify things in a way that align with reality and provide for the easiest user experience. They also leave room for expansion IF that is desired by some wallets or by users in the future but real-world experience tells us that while BIP32, 39, 43 and 44 are cool technically, in reality they aren't a pragmatic solution to the problem at hand (allowing users to remember a single set of recovery words). Note: #602 is what makes this whole system incompatible with cross-currency mnemonics. #601 and #600 don't have an impact on the cross-platformness of the whole solution.
Pragmatically, this isn't a situation the vast majority of users will ever find themselves in. Realistically the most common problem is loss/forgetfulness and requiring a password + mnemonic is no different from just storing the last 4 words of your mnemonic in a different location from the first Again, the simple extended mnemonic is intentionally designed to be as simple as possible and deal with the UX problems that the vast majority of people have to deal with in the real world. It is not designed to be some technical marvel or a system used by people with billions of dollars at stake and/or likely to be subject to targeted attacks by government agents. If you find yourself in a situation where deniability is a real necessity then you should use a different extended mnemonic. In fact, I recommend someone draft up an "ultra-secure-extended-mnemonic" of some kind that makes it so any password you provide results in a valid wallet. Then the user can fund faux accounts using the mnemonic and a "wrong" password, thereby providing as much deniability as they desire (e.g., could keep giving up passwords that keep yielding valid accounts). |
We agree. That's exactly what I said: "standards BIP39, BIP32 and BIP44 (with SLIP-0044)".
We agree here too. Different wallets not following the standard is the problem.
I think BIP44 allows to access the keys very well.
BIP44 is designed to have great flexibility so it can fit almost any kind of present and future cryptocurrency. If Ethereum does not need all the options BIP44 gives, that's fine.
BIP44 was not designed only for Bitcoin. BIP44 has a segment for every different coin. I quote the standard: "This level creates a separate subtree for every cryptocoin, avoiding reusing addresses across cryptocoins and improving privacy issues."
Then the solution is to clarify how it should be utilized in Ethereum.
It is very clear for Bitcoin which address should be incremented. The living proof is all Bitcoin wallets following BIP32, 44 and 39 have no compatibility problems. I can restore my BIP39 seed from Trezor into Mycelium and viceversa and all my Bitcoins and addresses appear without any problems. I am not against #600, #601 and #602, but I worry that If a new standard is created, the user will not be able to have one single mnemonic that can store all his/her private keys for Bitcoin and Ethereum. Do you think in the future one single mnemonic will restore all the user's bitcoins and ethers and work across all popular Bitcoin and Ethereum wallets? It is not a rhetoric question, I really want to know what you think. |
BIP39 checksum was already very short, specially for 12 words mnemonics. According to this EIP
If #602 are incompatible with BIP39, then in my opinion it would be better to improve BIP39 by changing the checksum to a larger one, for example a 32bit checksum. |
BIP44 was designed only with UTXO-based coins in mind, however; this is apparent from the purpose of the various segments. Further, BIP43 explicitly provides for multiple different derivation path schemes; nobody ever claimed that BIP44 should be good enough for everyone. Even Bitcoin devs agree with this reasoning; see this mailing list thread and this BIP PR.
It's not that simple, because any standardisation would require a migration path - preferably one that doesn't require users to manually enter the derivation path they used when they originally created their wallets. 602 provides a migration path for this.
This is a good demonstration of how the BIP44 path is well suited to UTXO based coins, but poorly suited to balance based coins.
Yes; if wallets that support multiple currencies implement 600/601/602, they can and should use the same mnemonic for Bitcoin and other coin addresses; there is nothing about 602 that makes it unsuitable for use with Bitcoin.
I don't personally view this as a significant issue; because mnemonics are word based, most user error will be caught because typos will not be valid mnemonics. The only situation in which this is likely is word transpositions. However, even in that case it is generally apparent to a user when they have restored the wrong wallet. Given the other protections available, I think a single bit reduction in the checksum is an acceptable tradeoff. You are, of course, welcome to define an EIP 602 mnemonic scheme with extra checksum data!
Every bit used for checksum is a bit that can't be used for entropy; a 32 bit checksum on a 12 word mnemonic would reduce the entropy to only 100 bits, which in my mind is an unacceptable tradeoff. On an unrelated note, it's been suggested to me that if we're breaking BIP39 compatibility anyway, this would be a good opportunity to make other changes; specifically, defining the seed to be the hash of the entropy, instead of the hash of the mnemonic words. This would have the advantage that you could translate mnemonics between different dictionaries (Eg, create the equivalent English mnemonic to a Japanese one), as well as some advantage in simplicity. I'd appreciate others' thoughts on this idea. |
That's what I meant. I agree reducing the entropy below 128 bits would not be a good trade off. Maybe the minimum length of the mnemonic should be 14 words? Maybe it would be good if the user could differentiate BIP39 mnemonics from EIP602 mnemonics at a glance. A different number of words makes it easy at a glance.
Yes I agree, I think it is an opportunity improve as much as possible from BIP39. I would not remove the feature of having an optional password. It is a great optional feature. |
One thing I quite like about BIP39 is that it treats words as triples: 3 words is 33 bits, which works out to 32 bits of entropy and 1 bit of checksum. Adding 2 words is 22 bits, which is a bit more awkward to divide up.
Definitely; that would still be possible via the 'password' scheme of 602. |
Therefore, the optional password will be removed from other schemes of 602. I think the password, like the checksum, should be an integral part of the mnemonic, not a specific feature of a specific scheme. |
Yes, because it doesn't necessarily make sense with all schemes. I also think it's a major UI benefit to be able to know when to prompt users for a password. |
It would be nice to know a scheme where it does not make sense to have the option.
In my opinion, Mycelium and many other wallets deal with it beautifully. |
My own forthcoming proposal for BIP38 style 'multiply mode encrypted wallets', for instance, which take a password/passphrase that is processed entirely differently to a regular mnemonic passphrase. More generally, I just don't see the benefit in having user confusion over whether a passphrase is required, when you can unambiguously signal its presence in metadata. |
|
I'll just respond to this since it appears @Arachnid has covered the rest.
I think this is a nice feature, especially for hardware wallets that support multiple chains (e.g., Ledger). However, I think BIP39 is a poor solution to this problem due to the fact that it doesn't encode enough information to actually fully solve the problem of "single mnemonic" (you also need a derivation path), which is why I am a fan of this solution as "the one mnemonic" rather than a BIP39 mnemonic as "the one mnemonic". |
That is a different feature. Right now with BIP39, you can provide any password (even an empty password) and a completely new valid wallet will be generated. It is one of the best BIP39 features. BIP38 style 'multiply mode encrypted wallets' does not allow that. To sum up, with EIP602, the user will have:
Maybe a 602 scheme that allows existing BIP39 features will be necessary. I just think it will be extremely unlikely existing popular wallets will be updated to be compatible with every EIP602 scheme. The user mnemonic will be trapped into a niche app that can actually understand a niche EIP602 scheme. That is the opposite of having one mnemonic that works across all popular Bitcoin and Ethereum wallets. |
The proposal I'm working on encodes multiply mode wallets in mnemonics. It can't use the BIP39 style scheme for applying passwords to a mnemonic.
Again, you can have a password, you simply have to use the appropriate encoding. I don't understand the attraction of encoding passwords without metadata to show they are present. Multiple wallets and deniability are still possible if you use a password protected wallet.
The whole point is that a user should not have to understand the difference; they should simply enter it into their wallet and it should work. What advantage would a visual difference between them bring to users?
This is a prerequisite for any improvement to the existing standard. As I pointed out earlier, expecting all Ethereum wallets to converge on a single BIP44 derivation path at this point is unrealistic, both because of the lack of a migration path for wallets not using the one decided on, and because of the unsuitability of BIP44 to blockchains that rely on balances instead of UTXOs. The first segment of derivation paths begins with the BIP number precisely because the developers foresaw the need for multiple different derivation path schemes, which provide a much neater solution than trying to shoehorn Ethereum address derivation into a UTXO scheme; something that has already been tried and failed.
To the best of my knowledge, there are no BIP39 features that EIP602 does not permit.
That's not the idea; not all mnemonic types will be supported by all wallets, but a user will be able to know when they enter it whether it's supported or not. This is, again, a prerequisite for any kind of innovation, and standing opposed to it is to imply that nobody should attempt to introduce new features without the entire ecosystem adopting them simultaneously. |
Perhaps you missed the section on
The user, no, but a UI can and that is what is important. How would you envision encoding the mnemonic so a user can tell the difference?
BIP39 mnemonics intentionally have a checksum that is inverse of the checksum for EIP602 mnemonics. This allows a UI that supports only BIP39 to correctly error to the user when they try to recover an EIP602 mnemonic and if the UI supports both then it will guess at how to handle the BIP39 mnemonic (e.g., default to BIP44 derivation path) and it will correctly handle the scenario if the provided mnemonic is EIP602. This EIP is designed to ensure that any UI that is prompting for a mnemonic can handle whatever is provided to it as gracefully as possible.
This seems to be your primary (and legitimate) gripe with this EIP so I recommend we focus discussion on it. Note that there is nothing stopping a wallet from supporting this new mnemonic and using it to generate a Bitcoin addresses as well as Ethereum addresses. An EIP602 mnemonic includes the seed and the derivation path which is all that is necessary to generate a set of BIP32 HD Wallet addresses for any chain. You are correct that anyone wanting to use this new path will need to use a wallet that has added support for it. I have spoken with a number of wallet authors in the Ethereum community and all of them would eagerly implement something like this because it solves some major UX headaches that have high support costs. I get the impression that you would prefer to solve the current Ethereum wallet ecosystem problem by getting everyone to agree on a particular usage of BIP44 derivation paths and continue using BIP39 mnemonics. Unfortunately, getting people to agree has proven incredibly difficult and part of the problem is the fact that BIP39 allows for any derivation path to be used. This EIP adds some constraints that make it so if you have a mnemonic, it defines exactly how that mnemonic should be used (what derivation path, password requirements, etc.). This removes the ambiguity present in BIP39+BIP44, allowing us to hopefully resolve this issue. |
I think you are right. I read the section "password protected extended mnemonics", but later I thought that was the scheme "BIP38 style". Let me see if I get it right, there will be at least 2 schemes to password protect the mnemonic:
If that is correct, then I am quite happy with EIP620 because in my opinion an essential feature from BIP39 will not be lost. Thank you for pointing to the root of my confusion. |
|
@Arachnid Would better be able to answer if there is any difference between EIP602 password protected wallets and BIP39 password protected wallets. Personally, I would prefer a 3rd option.
If I understand correctly, BIP39 is option 3 above, and right now this EIP specifies options 1 and either 2 or 3 (not sure which). |
|
That's right; the only difference between BIP39 password protected mnemonics and those defined in EIP602 is that whether or not a password exists is determined based on the mnemonic type, while the presence or absence of a password is not encoded in BIP39 at all. As such, any password will work, just like in BIP39. It'd be possible to specify a password-with-checksum option; such a scheme would need to define the data to contain type ID, password checksum bits, and entropy. I'd definitely support such a scheme; I'd like to hear what others think of either making it part of this EIP, or specifying it separately; the former would ensure wider compatibility, while the latter would reduce implementation complexity for wallets wishing to implement EIP602. Edit: Also, thanks to Micah for doing a better job of reducing ambiguity than me! |
I just want to point out, this is by design. Plausible deniability. |
Flagging whether there's a password or not doesn't remove plausible deniability; you can simply provide a duress password instead of the real one. |
Of course. But let's assume the 12-words are discovered or required to be given for whatever reason. A wallet with 12-words and no password but the presence of activity may be satisfactory to the attacker. It's the difference of the wallet owner taking action (providing duress password) and not doing anything. I wonder if providing a false duress password could be seen as "obstruction of justice" whereas doing nothing (not providing a password) may be seen as exercising right of free speech. I'm not a lawyer though... just providing some raw thoughts here. These scenarios require thinking about different adversaries of course. I'll have to dig into the details above, as there's a lot, but at this moment, I don't see the benefit of encoding the presence of a password. I'm assuming the benefits are stated above and I may read to find out. |
I can summarise: Usability. It's a bad user experience to take a user's (password protected) mnemonic, then present them with the wrong wallet because they haven't entered a password. It's equally bad to provide the user with an irrelevant password dialog that they don't need for a non-password-protected mnemonic. |
Quoting the section "Generating seeds from password protected extended mnemonics": No need to provide a duress password. |
|
@jprichardson To be clear, you can use a "password protected mnemonic" with an empty password if you like. As @Arachnid indicated, the goal here is to provide an option that is super easy for the vast majority of users that don't leverage complex systems for secret management. Most people just want something they can write down in a notebook on their desk that will allow them to recover their keys should they lose/break their hardware wallet or computer. For users that want to have a solution to the duress problem, password protected mnemonics are an option. We don't want to increase the complexity for dumb-user just because tinfoilhat-user won't use the simple option. We want to create options for both classes of users and then allow users to choose which route they want to take and allow the UI to identify which class of user they are dealing with. If we didn't have the information about whether or not a password was required then the UI would need to prompt the user for a password even if the user didn't set one up. This is confusing for dumb-user because when prompted for a password, they think it is required and they try to remember what they put (even though in this case they didn't put anything). They may never try "empty" password because they are taking the hint from the UI that a password is required and they have been trained that empty passwords are generally not allowed. |
|
Since I wrote this proposal, there's been some significant out-of-band conversation (see here for instance) on a better mnemonic replacement. As a result, I'd like to withdraw this proposal and go back to standardisation on something better. A couple of key insights:
|
I think you should close this PR then |
|
This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:
If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR. In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks. Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt: |
Use new formatting standard
This EIP specifies a method for generating mnemonic codes based on BIP39, while providing additional metadata for applications. This metadata makes new mnemonic-based applications possible, while also helping to standardise derivation paths in Ethereum-based applications.