From: slush <slush@centrum•cz>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged
Date: Thu, 12 Mar 2015 04:43:47 +0100 [thread overview]
Message-ID: <CAJna-HhHkmOTqNW2R6=Cih+tM_Eeu5o1LBxA4ZNzp-6vm1p6fg@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP2UrRYG2wh3DHHj9B3Sp1X=n+gPCRcoj1Fouu4Lg157UA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2724 bytes --]
On Wed, Mar 11, 2015 at 6:14 PM, Mike Hearn <mike@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
anything else.
Cheers,
Marek
[-- Attachment #2: Type: text/html, Size: 4001 bytes --]
next prev parent reply other threads:[~2015-03-12 4:50 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-01 15:23 Thomas Voegtlin
2015-03-02 7:09 ` Andreas Schildbach
2015-03-02 15:37 ` Mike Hearn
2015-03-02 17:11 ` Jim
2015-03-11 14:58 ` Thomas Voegtlin
2015-03-11 15:31 ` Andreas Schildbach
2015-03-12 8:56 ` Thomas Voegtlin
2015-03-11 17:14 ` Mike Hearn
2015-03-11 19:04 ` Jim
2015-03-11 19:24 ` Ricardo Filipe
2015-03-11 19:46 ` Gregory Maxwell
2015-03-11 22:57 ` Aaron Voisine
2015-03-11 23:22 ` Mike Hearn
2015-03-11 23:50 ` devrandom
2015-03-11 23:54 ` Mike Hearn
2015-03-12 0:11 ` Gregory Maxwell
2015-03-12 2:41 ` devrandom
2015-03-12 4:09 ` Gregory Maxwell
2015-03-12 19:08 ` Bryan Bishop
2015-03-12 10:30 ` Andreas Schildbach
2015-03-12 10:28 ` Andreas Schildbach
2015-03-18 2:06 ` devrandom
2015-03-12 10:41 ` Andreas Schildbach
2015-03-12 3:43 ` slush [this message]
2015-03-12 16:47 ` Mike Hearn
2015-03-12 17:20 ` Gary Rowe
2015-03-12 17:42 ` Gary Rowe
2015-03-12 18:27 ` Natanael
2015-03-12 18:51 ` Andreas Schildbach
2015-03-12 19:14 ` Natanael
[not found] <1353069350.4360497.1426126034565.JavaMail.yahoo@mail.yahoo.com>
2015-03-12 2:16 ` Thy Shizzle
2015-03-12 3:59 ` Neill Miller
[not found] <372541993.4372759.1426123313134.JavaMail.yahoo@mail.yahoo.com>
2015-03-12 2:26 ` devrandom
2015-03-12 2:38 Thy Shizzle
2015-03-12 10:43 ` Andreas Schildbach
2015-03-12 4:21 Thy Shizzle
2015-03-12 11:51 ` Neill Miller
2015-03-12 12:59 ` Thy Shizzle
2015-03-12 16:39 ` devrandom
2015-03-12 5:12 Thy Shizzle
2015-03-12 5:25 ` Aaron Voisine
2015-03-12 5:58 Thy Shizzle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJna-HhHkmOTqNW2R6=Cih+tM_Eeu5o1LBxA4ZNzp-6vm1p6fg@mail.gmail.com' \
--to=slush@centrum$(echo .)cz \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox