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 <m...@plan99.net> 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
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. http://goparallel.sourceforge.net/
Bitcoin-development mailing list