Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support use of abbreviated 4-letter BIP39 words #89

Open
gwillen opened this issue Feb 22, 2019 · 5 comments · May be fixed by #91
Open

Support use of abbreviated 4-letter BIP39 words #89

gwillen opened this issue Feb 22, 2019 · 5 comments · May be fixed by #91

Comments

@gwillen
Copy link

gwillen commented Feb 22, 2019

The BIP39 wordlists are selected so that the first 4 letters of each word are unique. The functions for working with mnemonics should accept them in that form, and expand them to the full words.

This is important because tools like the CryptoSteel / BillFodl metal key storage devices only accept the first four letters of each word, and making the user hand-expand that back to the whole word is painful and unnecessary.

Screwing around with the input in this way playing guess-what-I-mean is fine because of the checksum. As long as the checksum passes, we know we performed the correct expansion. (In light of this I think we should also offer user-friendly things like automatic casefolding to the same case as the dictionary. All of this should only be triggered after trying the entered string as-is and failing the checksum in that form.)

@greenaddress
Copy link
Contributor

@gwillen what are the pros/cons handling this at the GUI/app layer rather than at the wally layer?

Our mobile apps already suggest the right word at 4 characters or less depending on the word and i think you still need to keep the full dictionary to show it to the user to generate mnemonic etc

I am not against adding it though

@gwillen
Copy link
Author

gwillen commented Feb 27, 2019

We are using the wally layer to create python commandline tools. So we don't have any way to take advantage of autocomplete and such happening at higher layers. If there's another good approach for commandline tools I'm all ears!

@gwillen
Copy link
Author

gwillen commented Feb 27, 2019

(If the answer is that we should implement this in the tool, I don't disagree although it would be nice to get the benefit of all Wally's existing support for wordlists and such. Realistically this tool will probably never be used with anything other than the fixed BIP39 English wordlist, but I though more general support seemed likely to be useful.)

@greenaddress
Copy link
Contributor

makes sense - if it's done in wally then it can be reused in all lib/apps/cli/gui so happy to review PRs or anyhow add it to the features wishlist

@mword mword linked a pull request Feb 28, 2019 that will close this issue
@mword
Copy link

mword commented Feb 28, 2019

Just add a PR regarding this issue for your perusal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants