-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
BIP39: Adds Russian word list #432
Conversation
бушлат | ||
бывать | ||
быль | ||
быть |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"бывать" and "быть" are too similar imo and I would exclude both of them tbh
Also итак All of these above do not fit noun/verb/adj criteria - should be removed or mentioned in criteria imo. There also are some "numeric-like" words like "первый", "тысяча" etc which I'm not sure about too but probably they are ok. |
@UdjinM6 Thanks for comments, will go through them today, and push updated list to this PR. |
I've spend considerable amount of time manually going through word list and:
Please review and let me know if there are any issues left. |
Very nice! IMO the list looks much better now 👍 PS. And btw, thanks for submitting this PR! |
Here is some very familiar words I have found: |
this needs to be NFKD normalized, which you can do with the following perl script:
|
reviewed the words - looked OK. The list of words is also sorted so that's great. |
NFKD normalization needed. Be sure to resort after normalization. Japanese forgot to do so, :-( (oops!) |
Ping @farazdagi – Seems this still needs to be normalized? |
A general observation about adding more languages to BIP 39 is that English now has broad wallet support. If a new language is only supported by a small number of wallets, this could lead to (unintended) vendor-lockin. If someone writes down their mnemonic and puts in a vault, they should be able to take it out 50 years later and have a reasonable chance of finding software that can still import it. Perhaps getting BIP 39 (or something similar) recognized as an ISO standard would be a good step towards durability, before adding more languages. |
агат | ||
агент | ||
агрегат | ||
адажио |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
адажио is a quite rare word, is it okay to use it here?
Access to proposed wordlists not (yet) accepted into the BIP repository is now controlled by the -W option. This option is and will remain undocumented in the manpage and other user documentation. The purpose of this undocumented flag is to permit testing proposed wordlists and generating test vectors, without inducing users to rely on wordlists which may be changed or removed at any time without notice. Users MUST NOT generate actual wallets based on proposed wordlists; so doing could result in unrecoverable wallets and permanent funds loss. I am now ready to import three more proposed wordlists I had not hereto seen amongst BIP pull requests: - Russian, bitcoin/bips#432 - Ukrainian, bitcoin/bips#442 - Czech, bitcoin/bips#493 Wordlist already imported for testing, now hidden behind -W option: - Indonesian, bitcoin/bips#621 (b2f66ba, special-cased d03ddae) Further changes hereby made, with due apologies for a non-atomic commit: - Integrating the -W option necessitated a general cleanup and overhaul of the options-handling code. - Whilst overhauling the options, I noticed that the documented -P option functionality was broken/nonexistent. Fixed.
Notice: This is hidden behind the -W flag; see 8aaa6f3. This is not exactly the wordlist proposed in the pull request. It is the russian.txt from farazdagi/bips@a59cc3e, as modified by approximately the following command: uconv -f utf-8 -t utf-8 -x '::nfkd;' | sort -s The *result* has been confirmed to not have any leading BOM, and to have a final line terminated with '\n' (bitcoin/bips#622). I did not yet examine the source for these issues. The *result* russian.txt SHA-256 hash: a8d7b9d8bdd3816eddd2aeb98718ad586d8e7dd8c364a944c072cdf3cd6bcb05
@Sjors BIP39 states
And
Which means "If you can't detect (or don't know the wordlist) the checksum, show a warning, but ALLOW THE SEED TO BE GENERATED" But almost every single wallet used their "developer common sense" which states "if there exists a checksum. Always check it, and always fail loudly and stop everything"... which makes sense. It is the fault of BIP39 which was made to contradict developer common sense that is at fault. But to be honest. Electrum supports all BIP39 wordlists, because it actually follows the BIP, and if it doesn't recognize the wordlist, it shows a warning but generates the wallet anyways. I have recovered many wallets using Electrum. Ironically, Electrum's developer pointed out this contradiction, the authors ignored it, Thomas asked to have his name removed because of this and other problems, and now Electrum is the only wallet that implements BIP39 correctly in this aspect. |
At nym-zone/easyseed@234c66c, I have created a Unicode NFKD-normalized and binary-sorted
(I originally forgot to force the The result has been confirmed to not have a leading BOM, and to have a final line terminated with '\n' (#622). I did not yet examine the source for these issues. SHA-256 hash for the resulting |
The answer to vendor lock-in is independent implementations. BIP 39’s simplicity facilitates that. In ten days of occasional side-work, I have written a BIP 39 implementation with extensive self-tests which generates mnemonics in any language for which a wordlist is available in the BIP repository. It can output a BIP 32 I have C code on my disk with copyright dates from almost 40 years ago—actually, if memory serves, the oldest date I have seen in my platform’s source tree is exactly 1978. Likewise, I expect that my freely available C11 code will compile with minimal changes for decades to come. When such tools are available and easy to produce ab initio, where is the vendor lock-in? Wallets don’t need multi-language support to restore from an I am glad to see new languages being proposed and added. The important part is to get the wordlist right before it’s carved into the standard, baked into implementations, and used for wallets containing actual people’s actual money. That is important. |
These are generated with easyseed and the bip39_vectorgen.sh script from 5f35cd0. There are vectors in twelve languages: The eight in the BIP repository, and four more with pending proposals. Three of the vectors for proposed languages are for wordlists which I have modified: - Russian (234c66c, bitcoin/bips#432) - Ukrainian (08a05b4, bitcoin/bips#442) - Czech (ba25dfa, bitcoin/bips#493) The wordlist for Indonesian (bitcoin/bips#621) is unmodified from the proposal. Ironically, easyseed does not yet self-test itself with these. That will be added in a future release, to verify consistency between builds. For now, I publish these to aid in interoperability testing between implementations.
So is it ok to implement this Russian wordlist in the wallet? What are the rules of accepting language to BIP39 by the community? |
You can implement any wordlist you want, and Electrum will properly recover it. (Though it will not detect checksum errors) Other wallets are poorly implemented. |
I've tried to follow guidelines defined in other languages.