Yes I agree with this sentiment.
As for the version, don't forget we can kinda "brute force" our way to 
determine a version, because lets say there is 10 versions, we can generate the 
seed for all 10 versions and then check to see which seed was in use (has 
transacted) and then use that seed. If no transactions are found, we could 
restore the wallet with the seed of the latest and greatest version. Not really 
any need to store the version, sure it may save some time but as Marek rightly 
says, this is for restoration of a wallet from cold storage not an everyday 
thing so the extra time to brute force the version etc is acceptable as a trade 
off for not forcing the remembering of a version.
BIP39 is beautiful.
On Wed, Mar 11, 2015 at 6:14 PM, Mike Hearn <> wrote:

   - Electrum v2 with a version number but no date
   - myTREZOR with no version and no date and BIP44 key derivation. Some seeds 
I believe are now being generated with 24 words instead of 12.
   - MultiBit HD with no version and a date in a custom form that creates 
non-date-like codes you are expected to write down. I think BIP32 and BIP44 are 
both supported (sorta).
   - GreenAddress with no version, no date and BIP32
   - Other bitcoinj based wallets, with no version and a date written down in 
normal human form, BIP32 only.

To my knowledge, myTREZOR, Multibit HD and GreenAddress uses BIP39, just 
different scheme for key derivation (myTREZOR uses full BIP44, Multibit HD uses 
BIP44 with first account only and GreenAddress uses another scheme because it's 
multisig only wallet).
I disagree with the need of some version "magic flags" or creation date stored 
in the mnemnonic, for those reasons:
a) If we fail in the way how mnemonic algo is defined, then some magic, extra 
version flag won't save our asses, because we'll fail in meaning of its 
meaning. Then it will be completely useless, as implementations cannot rely on 
it. I know Thomas was sound proponent of this solution, but he was unable to 
give any reasonable rules about who/how define meaning of version flag.
b) "Creation date" is just a short-term hack. Considering that mnemonic words 
are kind of cold storage (longterm storage), it *really* does not make much 
difference in 2020, if your wallet has been created in 02/2014 or 10/2016. If 
there's performance issue with scanning of the blockchain, creation date don't 
save our asses. We need to find another solution, and as a bonus, we don't need 
users to know some weird numbers on top of mnemonic itself.
> From my interpretation of BIP39, wordlists DO NOT REQUIRE to be fixed between 
>wallet providers. There is some recommendations regarding the wordlists to 
>help with things such as predictive text, so mobile apps can easily predict 
>the word being typed in after a few chars etc.
Exactly! After some community feedback, we changed BIP39 algo to be one-way 
only, which means you can use *any* wordlist to create the mnemonic, and any 
other implementation can derive BIP32 root node even without knowing that 
particular wordlist. Namely this has been changed because of constructive 
criticism of ThomasV, and from discussion on the mailing list I had a feeling 
that we've found a consensus. I was *very* surprised that Electrum 2.0 started 
to use yet another algo "just because".
Shortly said, I think BIP39 does perfect job and there's no need to use 
anything else.
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now.
Bitcoin-development mailing list

Reply via email to