Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YVt1B-0000xR-RN for bitcoin-development@lists.sourceforge.net; Thu, 12 Mar 2015 02:38:37 +0000 Received: from nm39-vm5.bullet.mail.bf1.yahoo.com ([72.30.239.149]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YVt1A-0006dy-3V for bitcoin-development@lists.sourceforge.net; Thu, 12 Mar 2015 02:38:37 +0000 Received: from [98.139.215.143] by nm39.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2015 02:38:30 -0000 Received: from [98.139.212.238] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 12 Mar 2015 02:38:30 -0000 Received: from [127.0.0.1] by omp1047.mail.bf1.yahoo.com with NNFMP; 12 Mar 2015 02:38:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 788149.97265.bm@omp1047.mail.bf1.yahoo.com X-YMail-OSG: RmkiVwgVM1mc8G1nfuGlzF_t0IiE1IKykNfM7F1r1.UdtQY.DezuKzVhEsp8.R_ q.Rh9ODcqruR199uL300ptvFuxMSUp8XhtfHvDsWPb.iJ8NFnumJNfWrSv50pPLDa0Qa4Y_piOw3 SOCnzxWUr2qwFgeebrMhh3jqaUYUsp_zVIi.WV7g7QdyL0o.TQi7yO09hreJzivmQEmA5tOt8XEf 6kCjvm7Io4_.ltfTDjy98TeexwFizrC3NVH7zIP_FRiQ6dB2sR1w6GH61yx4seNghz61WpBVMT.9 iOUTqVis1K.yB.zCcTrwg1Oa25RuguiRJdnG9j1_.nMKZrp6LQbNGaW_vCzhruw9z2dp0nCPytTN BI9y2uOVceNJIiAijQMGMdReg1OWFuRqeDxS0LNTQw.NQYqrPJVz77S7NtQITJuhGUyHKjZ0red. kH7snh9BryBKiaFtDhid50MhTzRbOkh0MMR6tgWVZUJn3WOhIb36lIY8GdkRxw2bOE9nzOqMduP5 LA1.EIHJlsFx5EhbxB6fU Received: by 66.196.81.110; Thu, 12 Mar 2015 02:38:30 +0000 Date: Thu, 12 Mar 2015 02:38:29 +0000 (UTC) From: Thy Shizzle To: "c1.sf-bitcoin@niftybox.net" Message-ID: <190821851.4415282.1426127909995.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4415281_641691130.1426127909992" 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.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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [72.30.239.149 listed in list.dnswl.org] 0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YVt1A-0006dy-3V 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 02:38:37 -0000 ------=_Part_4415281_641691130.1426127909992 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Right you are! I saw Thomas's email about Electrum 2.0 not supporting BIP39. It seems he had the idea that the wordlist was a strict requirement yet it = is not, it is unfortunate that Electrum did not go the route of BIP39. The = wordlist is irrelevant and merely used to help build mnemonics. Also as I've shown, you can work a version into it, I was going to actually= propose it to the BIP39 authors but didn't think it was an issue. I think BIP39 is fantastic. I think Electrum 2.0 (And everyone)=C2=A0should use BIP39=C2=A0 On 2015-03-= 11 06:21 PM, Thy Shizzle wrote: > Hmmmm I don't think it's fair to say that there has been a failure to > standardise. From what I read earlier among the wallets, mostly it came > down to if a version was noted and the date. Assuming no date is > provided, it just means you are scanning the block chain from day 0 for > transactions right? Hardly a big deal as you will still recover funds rig= ht? Unfortunately there's more incompatibility than just the date issue: * seed: some follow BIP39, and some roll their own * HD structure: some follow BIP44, some BIP32 derivation, and some roll their own So actually very few wallets are seed-compatible, even ignoring the date question. >=20 > Version right now is irrelevant as there is only one version of BIP39 > currently, probably this will change as 2048 iterations of HMACSHA512 > will likely need to be up scaled in the future, I thought about adding > one extra word into the mnemonic to signify version, so if you have a 12 > word mnemonic then you have 12 words + 1 word version. Version 1 has no > extra word, version 2 uses the first word on the list, version 3 uses > the second word on the wordlist, so on and so forth. Least that's what I > was thinking of doing if I ever had to record a version, won't effect > anything because entropy increases in blocks of 3 words so one extra > word can simply be thrown on the end. That's a reasonable solution. >=20 > So in summary I feel that date can be handled by assuming day 0, and > version is not an issue yet but may become one and probably it is a good > idea to think about standardising a version into BIP39, I have > provided a seed idea for discussion. >=20 > I don't think it is quite the doom and gloom I'm reading :) >=20 >=20 > devrandom: > "I'd like to offer that the best practice for the shared wallet use case > should be multi-device multi-sig.=C2=A0 The mobile has a key, the desktop= has > a key and a third-party security oracle has a third key.=C2=A0 The oracle > would have different security thresholds for countersigning the mobile. >=20 > This way you can have the same overall wallet on all devices, but > different security profiles on different keys. >=20 > That said, I do agree that mnemonic phrases should be portable, and find > it unfortunate that the ecosystem is failing to standardize on phrase > handling." --=20 devrandom / Miron ------=_Part_4415281_641691130.1426127909992 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right you are!

I saw Thomas's email about Electrum 2.0 not supporting B= IP39.

It seems he had= the idea that the wordlist was a strict requirement yet it is not, it is u= nfortunate that Electrum did not go the route of BIP39. The wordlist is irr= elevant and merely used to help build mnemonics.

Also as I've shown, you can work a version into= it, I was going to actually propose it to the BIP39 authors but didn't thi= nk it was an issue.

I think BIP39 is fantastic.

I think Electrum 2.0 (And everyone) should use BIP39
 
On 2015-03-11 06:21 PM, Thy Shizzle wrote:
> Hmmmm I don't think it's fair to say that there has been a failure to<= br> > standardise. From what I read earlier among the wallets, mostly it cam= e
> down to if a version was noted and the date. Assuming no date is
> provided, it just means you are scanning the block chain from day 0 fo= r
> transactions right? Hardly a big deal as you will still recover funds = right?

Unfortunately there's more incompatibility than just the date issue:

* seed: some follow BIP39, and some roll their own
* HD structure: some follow BIP44, some BIP32 derivation, and some roll
their own

So actually very few wallets are seed-compatible, even ignoring the date question.

>
> Version right now is irrelevant as there is only one version of BIP39<= br> > currently, probably this will change as 2048 iterations of HMACSHA512<= br> > will likely need to be up scaled in the future, I thought about adding=
> one extra word into the mnemonic to signify version, so if you have a = 12
> word mnemonic then you have 12 words + 1 word version. Version 1 has n= o
> extra word, version 2 uses the first word on the list, version 3 uses<= br> > the second word on the wordlist, so on and so forth. Least that's what= I
> was thinking of doing if I ever had to record a version, won't effect<= br> > anything because entropy increases in blocks of 3 words so one extra > word can simply be thrown on the end.

That's a reasonable solution.

>
> So in summary I feel that date can be handled by assuming day 0, and > version is not an issue yet but may become one and probably it is a go= od
> idea to think about standardising a version into BIP39, I have
> provided a seed idea for discussion.
>
> I don't think it is quite the doom and gloom I'm reading :)
>
>
> devrandom:
> "I'd like to offer that the best practice for the shared wallet use ca= se
> should be multi-device multi-sig.  The mobile has a key, the desk= top has
> a key and a third-party security oracle has a third key.  The ora= cle
> would have different security thresholds for countersigning the mobile= .
>
> This way you can have the same overall wallet on all devices, but
> different security profiles on different keys.
>
> That said, I do agree that mnemonic phrases should be portable, and fi= nd
> it unfortunate that the ecosystem is failing to standardize on phrase<= br> > handling."

--
devrandom / Miron
------=_Part_4415281_641691130.1426127909992--