I have a situation where I need to access a word in some language by some index [0, 2047]. It does not seem like it's currently possible to do this.

Specifically, I am attempting to implement the current SeedQR encoding used by @SeedSigner. The encoding is a list of length n of 4-digit numbers each corresponding to an index in the word list.

I can submit a PR addressing this issue, but I would like to hear the maintainers' opinion as to the best way to do it. The simplest solution that comes to mind would be to make Language::word_list public instead of just create-visible.

The latest version of this crate 1.0.1 was released on April 1st, 2021 - over 1 year and 8 months ago. Since then, there's been a PR to add Zeroize support which we'd like to use without having to specify a git dependency. Would you mind cutting a new release so we can use the zeroize feature via crates.io?

For example in

It would be helpful to be able to access this function (and others that return a Vec) with no_std, if one has access to alloc (alloc::vec::Vec)

A new feature alloc could be added and used instead of std for Vec.

For example: Mnemonic::generate, Mnemonic::generate_in and Mnemonic::generate_in_with are completely omitted from the API documentation, and there is no mention of the features that enable them:

From the API documentation alone, one would have no idea that this functionality exists or how to use it.

Instead, these feature gated items should appear in the API documentation along with a marker that identifies them as being available only with certain crate features enabled. Here is an example of how it should look taken from the k256 crate:

.

crates.io and docs.rs list this to be the same crate as https://github.com/infincia/bip39-rs/, just a newer release of it. As far as I can tell they are two completely different implementations of bip39 with no relation to each other. This seems dangerous to me.
https://crates.io/crates/bip39/versions

After #41 merges we can checek over the crate and remove unwanted extern crate e.g., in rustdoc examples

Hi team, this lib pegs [email protected]. It's now up to [email protected], so it would be good to upgrade before it diverges too much. I have to downgrade other libraries several versions to make this work.

I'll raise a PR if I've got some time next week.

The JavaScript npm implementation of BIP39 allows word counts divisible by 3:
https://github.com/bitcoinjs/bip39/blob/5faee2c17b2195f30b03cb125df68c20d7dd584b/src/index.js#L72
Same in the Python reference implementation linked from the BIP0039 wiki page:
https://github.com/trezor/python-mnemonic/blob/75629ff0e1a2dec7fbb3aa2c70a964c9023db5b4/src/mnemonic/mnemonic.py#L129
Real life example: The Yorio wallet for Cardano uses 15 words.
So this should be changed as well in this code:
https://github.com/rust-bitcoin/rust-bip39/blob/master/src/lib.rs
Looks like there are 2 occurrences of % 6. This should be refactored to a constant, and probably % 3, so that it is the same as in the npm library, or testing for the fixed set [12, 15, 18, 21, 24], as used in the Python reference implementation.

The canonical implementation of Mnemonic::generate_in_with generates the following errors:

the trait `rand_core::RngCore` is not implemented for `ThreadRng`
the trait `rand_core::RngCore` is not implemented for `ThreadRng`

Is there a reason an older version of rand_core is being used?

Is this project still maintained and are there any plans for a release? I noticed the last release on crates.io was about a year and a half ago, but it appears there have been several desirable feature upgrades merged into master since then.

@stevenroose would you be open to adding additional maintainers on this repo? I know you're taking care of a bunch of other repos and it looks like this one hasn't been getting enough attention in terms of ACK'd PRs being merged and creating regular releases. I ask because this repo is a dependency for bitcoindevkit/bdk. I found a dev from the BDK team, @vladimirfomene who said he'd be happy help out as a maintainer, he's currently also the maintainer for the bitcoindevkit/rust-esplora-client repo. And/or @tcharding are you able to help?

The words are currently stored as

pub const WORDS: [&str; 2048] = [

This carries an overhead of 16 bytes per element (8 bytes pointer to data and 8 bytes length), which is an overhead of ~32kB.

You can verify this with:

println!("{}",` std::mem::size_of_val(&WORDS))   

This is not great for embedded use (in 32 bit systems the overhead is half as big but it is still very big).

It would be way more efficient to store the words as one big &str plus array of indices for the word boundaries

Would you be open to a PR that implements this behind a feature? The Language::words_by_prefix() and Language::wordlist() functions would be disabled if this feature was active. Instead a get_word(idx: usize) -> Option<'static str> method would be added, which would still allow users to access the words efficiently.

Is the to_seed_normalize" the canonical way to add a bip39 passphrase in this crate?

If so, would it be possible to rename the method? Something like "add_passhphrase" would be very obvious to someone new.

Or making the canonical way to add a passphrase much clearer in the API in some other manner. The current method name and its arguments are not very obvious.

Is there a specific reason for this repo to not have a Cargo.lock?

I need to build this package with Nix and the Cargo.lock is required. It wouldn't make sense to generate this during build, in this case.

Either this https://github.com/stevenroose/rust-bip39/blob/c4f7a37b5cd6e9a6f756768dc7a61df37c80a5ea/src/lib.rs#L218 or this is false https://twitter.com/LeoWandersleb/status/1278378965435105280?s=19

I am on mobile at the moment, can't check

would passphrase support fit in this library? It is part of the BIP and is very useful for hot wallets.

This crate uses version 0.6 of the rand crate and is incompatible with the latest 0.8

Why does Mnemonic::parse_in_normalized_without_checksum_check exist? Isn't the main usefulness of this crate the fact that Mnemonic instances are guaranteed to be valid? Now if someone writes an application that presents a Mnemonic to a user, they have to manually trace the source of its initialization and make sure it wasn't created with parse_in_normalized_without_checksum_check or else they risk presenting an invalid mnemonic.

It makes sense for possibly-invalid mnemonics and operations thereof to be in scope of this crate, but I feel like their implementation shouldn't break the checksum validity invariant of Mnemonic. That way, application authors can simply trust that Mnemonic instances are valid.