Regarding false positive rates, an 8-bit version field would result in an nVersion/256 false positive rate.
Assuming support for three versions, this would yield a false positive rate of less than 1.2%.
If this isn't enough, one option is to use the 24-bit general purpose field to mitigate this.
This has already been addressed by Lukechilds here : https://github.com/lukechilds/bip39-versioned?tab=readme-ov-file#false-positives

From what I know these are the main criticism:
(https://pkg.go.dev/github.com/lightningnetwork/lnd/aezeed#section-readme)

Given the limitations of non-versioned BIP39 mnemonic phrases, it's equally important to consider the benefits that versioning could bring.
It's essential to design systems with forward compatibility in mind to ensure their long-term relevance and adaptability.

Thanks for your feedback !

The VF is indeed prepended to the entropy, I agree that  ENT + VF might be confusing. Read it as (ENT + 32)
I was referring to the number of bits of the checksum, basically it's the same way to compute the checksum as per BIP39.

Yes the 24-bit general purpose field can include any data which will be interpreted by the software depending on the version number.

The combined entropy of the seed phrase will look like:
24 general purpose bits + 8 version bits + entropy bits + checksum


Yes, it'll work exactly the same as long as the KDF is the same.
Passphrases would work with other KDFs too as long as they support salting.

Thanks for your feedbacks!


I deliberately refrained from drafting specifications for the versions, as I believe that falls outside the scope of this proposal.
However, if I were to design a version dedicated to specifying derivation paths, I would consider utilizing the 24-bit purpose field.

Personally, I envision two methods to achieve this:

• Employ the entire 24-bit field to define a custom derivation path. This approach, however, would limit the mnemonic phrase to a single derivation path.
• Alternatively, use 16 bits to designate standard derivation paths, allocate the subsequent 8 bits for subversions (allowing for future expansion of these standard paths).

For example:
first bit     - m/44'/0'/0'
second bit - m/49'/0'/0'
third bit    - m/84'/0'/0'
fourth bit  - m/86'/0'/0'

where:
0001 0000 0000 0000 - m/86'/0'/0' only
1001 0000 0000 0000 - m/44'/0'/0' & m/86'/0'/0'
1111 0000 0000 0000 - all of the above derivation path


I believe that, ultimately, a compromise is necessary between the flexibility of setting a custom derivation path and the capability to utilize multiple derivation paths simultaneously.



Yes, to maintain compatibility with non-versioned BIP39 wallets, the complete set of 15 words must be entered into PBKDF2.
Of course, this could be changed in future versions, albeit at the cost of breaking compatibility.


I agree that it'd be a bad idea.

[1] If the security issue you are referring to involves the use of PBKDF2, this could be addressed by implementing versioning, although it would break compatibility with non-versioned BIP39 software.

[2] Correct, a 128-bit entropy results in a 15-word mnemonic when considering the 24-bit general-purpose field is used.
For a 12-word mnemonic phrase under the versioned BIP39, you can attain a maximum of 120 bits of entropy, whereas the non-versioned BIP39 allows for 128 bits of entropy with a 12-word mnemonic.

Hello, and thank you for your interest!

The primary criticisms of BIP39 that I have encountered include:

• The absence of versioning.
• The reliance on a fixed wordlist for checksum verification.

Implementing versioning and a general purpose field could offer several advantages, such as:

• Specifying the derivation path.
• Including the wallet's birthdate.
• Modifying the Key Derivation Function (KDF).
• Enhancing error detection and correction capabilities.
• Indicating whether a passphrase is used.
• Facilitating improved methods of seed xoring.
• And more...

Regrettably, I don't foresee a method to maintain compatibility with legacy software (non-versioned BIP39) while simultaneously eliminating the requirement for a fixed wordlist.
The objective here is not to introduce a new algorithm, but rather to incorporate versioning while remaining consistent with the BIP39 standard.

I'm currently involved in a proposal to add a version field to BIP39 mnemonic phrases, an idea that isn't new but one I believe is worth exploring further.
I would really appreciate your feedback on this.
The details of the proposal are outlined in the mailing list, and I'm seeking insights and thoughts from the community on this concept.

For more information, please visit the mailing list at https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2024-January/022275.html

Looking forward to hearing your opinions!