From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YVv4i-0004ua-LX for bitcoin-development@lists.sourceforge.net; Thu, 12 Mar 2015 04:50:24 +0000 X-ACL-Warn: Received: from mail-wi0-f176.google.com ([209.85.212.176]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YVv4g-0002uk-Ob for bitcoin-development@lists.sourceforge.net; Thu, 12 Mar 2015 04:50:24 +0000 Received: by wiwl15 with SMTP id l15so17171246wiw.0 for ; Wed, 11 Mar 2015 21:50:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=ZITejQNzKYyhxX2wdHVd9Z4xgu+HXlIaLcjmSEXl+pw=; b=fEgApvjVxdT7N8Q5r29RlVWyD45pgDkEFRJGeO9gOOqe+U1aN+oCJthZhru+gTPS8c C6Fb2rCDBRRad9iXqE1qYB2EUUL9HegMeoqTinjGRd8WW9BafXYaahhwyIBjj3PGgpQZ Rp9r6fjExJ61cvqTPUCvRlx/SXF+R+tgnRaLGh5exyLj/fvmJYAwtCzZKs+JlG0GS0hn U3cqpWpcfxP8G0u2/Qj6ffHHTRP2M1GIum/oWBM/uCMvBGVBjQRHTkxm2R+CY4MSsz7N mdPuzPGlVJtQIne1m0rp+Td8bQrmK/RL7hzId/bRIwzdhjY3qD/95eNbQZj1mU26u9uy RCiQ== X-Gm-Message-State: ALoCoQmxNJlfjCUXNATiTuwN7+oc5Z+24M0j3/pa1PxhqGaMiKnqWcRz33owsEVByLJyaKa+Wq0b X-Received: by 10.194.63.16 with SMTP id c16mr84547678wjs.117.1426131858028; Wed, 11 Mar 2015 20:44:18 -0700 (PDT) MIME-Version: 1.0 Sender: marek@palatinus.cz Received: by 10.28.180.138 with HTTP; Wed, 11 Mar 2015 20:43:47 -0700 (PDT) In-Reply-To: References: <54F32EED.6040103@electrum.org> <550057FD.6030402@electrum.org> From: slush Date: Thu, 12 Mar 2015 04:43:47 +0100 X-Google-Sender-Auth: k1uRNVRVv7a9xZ_ptrtLdRZFKco Message-ID: To: Mike Hearn Content-Type: multipart/alternative; boundary=047d7b86da3acd14a705110f3247 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (slush[at]centrum.cz) 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1YVv4g-0002uk-Ob Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 04:50:24 -0000 --047d7b86da3acd14a705110f3247 Content-Type: text/plain; charset=ISO-8859-1 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. Cheers, Marek --047d7b86da3acd14a705110f3247 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


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 w= ith 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
  • O= ther bitcoinj based wallets, with no version and a date written down in nor= mal human form, BIP32 only.
To= my knowledge, myTREZOR, Multibit HD and GreenAddress uses BIP39, just diff= erent 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 t= he 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 gi= ve 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 be= en created in 02/2014 or 10/2016. If there's performance issue with sca= nning 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 som= e weird numbers on top of mnemonic itself.

>=A0= From my interpretation of B= IP39, wordlists DO NOT=A0REQUIRE to be fixed between wallet providers.=A0Th= ere is some recommendations regarding the wordlists to help with things suc= h as predictive text, so mobile apps can easily predict the word being type= d 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 mn= emonic, and any other implementation can derive BIP32 root node even withou= t 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 t= hat Electrum 2.0 started to use yet another algo "just because".<= /span>

Shortly said, I think BIP39 does perfe= ct job and there's no need to use anything else.

Cheers,
Marek
--047d7b86da3acd14a705110f3247--