From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YVvQV-0007fs-Tr for bitcoin-development@lists.sourceforge.net; Thu, 12 Mar 2015 05:12:55 +0000 Received: from nm4.bullet.mail.bf1.yahoo.com ([98.139.212.163]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YVvQT-0002AL-LT for bitcoin-development@lists.sourceforge.net; Thu, 12 Mar 2015 05:12:55 +0000 Received: from [66.196.81.172] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2015 05:12:48 -0000 Received: from [98.139.212.240] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2015 05:12:48 -0000 Received: from [127.0.0.1] by omp1049.mail.bf1.yahoo.com with NNFMP; 12 Mar 2015 05:12:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 309711.86930.bm@omp1049.mail.bf1.yahoo.com X-YMail-OSG: 1dMnDy0VM1lbY2asJ.VHMXwryL9cwehoHtYwU6LRlf1a6YeL1.ohBDTXpi41fBm XpB.mKeIHHRvTswJl_YV.XBDsWAv7sKtvlpwUW_4OEDiStoiMWBHchl1jX.vPE9LbQpgmzXR2F.D R6ZEnTFjvRMlY9yxvCzZCYVgwL6NCTUl0_9vxi3DrvV4jYGC24GQ_XFwsxsFhCvS2XgFfXOnlYP5 RfoFcf28ALfo3s95g8qULZsgcFxzMLJjKi2tH2BUYkcxDvRwO7CrFnGzjSijnCc4YnWtFUdXKOl3 iLZcIaNijUnoGQb7xGYi.6X.IR_MZo9dcYLlFnf_WmWXyU70Ui7osng7vde5SOUAhmPB4nak11vI _Zs9bbDF5efnBX6lAKRbUjHJRoGqRdBihcoGZ5AWipAWsbvHdKDZiKMATZq8v070k7GO7ArVFUDE pz2QzFimewdDe7OmLiO4ncZjpbl9gkHwW6qiTn9xl9krI9cLeIu3Hsh8MEcHF3kJnI_QIPbr7hT. LGCOCgE9aS.7a_WdI9z4W Received: by 66.196.81.105; Thu, 12 Mar 2015 05:12:47 +0000 Date: Thu, 12 Mar 2015 05:12:47 +0000 (UTC) From: Thy Shizzle To: "slush@centrum.cz" Message-ID: <892666269.4459743.1426137167385.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4459742_498376856.1426137167380" X-Spam-Score: 1.2 (+) 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 (harro84[at]yahoo.com.au) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [98.139.212.163 listed in list.dnswl.org] 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (harro84[at]yahoo.com.au) 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YVvQT-0002AL-LT Cc: "bitcoin-development@lists.sourceforge.net" 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 Reply-To: Thy Shizzle List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 05:12:56 -0000 ------=_Part_4459742_498376856.1426137167380 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes I agree with this sentiment. As for the version, don't forget we can kinda "brute force" our way to dete= rmine 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 re= ally 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 accepta= ble 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: =20 - Electrum v2 with a version number but no date - myTREZOR with no version and no date and BIP44 key derivation. Some se= eds 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 n= on-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 di= fferent scheme for key derivation (myTREZOR uses full BIP44, Multibit HD us= es BIP44 with first account only and GreenAddress uses another scheme becau= se it's multisig only wallet). I disagree with the need of some version "magic flags" or creation date sto= red in the mnemnonic, for those reasons: a) If we fail in the way how mnemonic algo is defined, then some magic, ext= ra 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 unab= le to give any reasonable rules about who/how define meaning of version fla= g. b) "Creation date" is just a short-term hack. Considering that mnemonic wor= ds are kind of cold storage (longterm storage), it *really* does not make m= uch difference in 2020, if your wallet has been created in 02/2014 or 10/20= 16. 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. >=C2=A0From my interpretation of BIP39, wordlists DO NOT=C2=A0REQUIRE to be= fixed between wallet providers.=C2=A0There is some recommendations regardi= ng the wordlists to help with things such as predictive text, so mobile app= s 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 a= ny other implementation can derive BIP32 root node even without knowing tha= t particular wordlist. Namely this has been changed because of constructive= criticism of ThomasV, and from discussion on the mailing list I had a feel= ing 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 any= thing else. Cheers,Marek ------=_Part_4459742_498376856.1426137167380 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes I agree with this sentiment.

As for the version, don't forget we ca= n kinda "brute force" our way to determine a version, because lets say ther= e is 10 versions, we can generate the seed for all 10 versions and then che= ck 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 th= e latest and greatest version. Not really any need to store the version, su= re 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 b= rute 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, 201= 5 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 deriv= ation. Some seeds I believe are now being generated with 24 words instead o= f 12.
  • MultiBit HD with no v= ersion 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 vers= ion, no date and BIP32
  • Othe= r bitcoinj based wallets, with no version and a date written down in normal= human form, BIP32 only.
To my knowledge, myTREZOR, Multibit HD a= nd GreenAddress uses BIP39, just different scheme for key derivation (myTRE= ZOR uses full BIP44, Multibit HD uses BIP44 with first account only and Gre= enAddress 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, th= en 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 implement= ations cannot rely on it. I know Thomas was sound proponent of this solutio= n, but he was unable to give any reasonable rules about who/how define mean= ing of version flag.

=
b) "Creation date" is ju= st a short-term hack. Considering that mnemonic words are kind of cold stor= age (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 performan= ce issue with scanning of the blockchain, creation date don't save our asse= s. 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.
<= div>
E= xactly! 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 an= y 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 feeli= ng that we've found a consensus. I was *very* surprised that Electrum 2.0 s= tarted to use yet another algo "just because".

<= div>
Shortly said, I think BIP39 does perfect job and there's no need t= o use anything else.

Cheers,
Marek
------=_Part_4459742_498376856.1426137167380--