diff options
author | Thy Shizzle <thashiznets@yahoo.com.au> | 2015-03-12 02:38:29 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-03-12 02:38:37 +0000 |
commit | b82833c00025861a48563fbde0d4f23c9d73cbe3 (patch) | |
tree | d9f395ff71d8258ee47effbd8df045485303af4b | |
parent | 2fd61ad75dd6f0541416713eaa789cd3e000b248 (diff) | |
download | pi-bitcoindev-b82833c00025861a48563fbde0d4f23c9d73cbe3.tar.gz pi-bitcoindev-b82833c00025861a48563fbde0d4f23c9d73cbe3.zip |
Re: [Bitcoin-development] Electrum 2.0 has been tagged
-rw-r--r-- | c8/258a2b67c6e7a8d59d36bee8d45061508830ec | 241 |
1 files changed, 241 insertions, 0 deletions
diff --git a/c8/258a2b67c6e7a8d59d36bee8d45061508830ec b/c8/258a2b67c6e7a8d59d36bee8d45061508830ec new file mode 100644 index 000000000..b8c5a29b9 --- /dev/null +++ b/c8/258a2b67c6e7a8d59d36bee8d45061508830ec @@ -0,0 +1,241 @@ +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 <harro84@yahoo.com.au>) 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 <thashiznets@yahoo.com.au> +To: "c1.sf-bitcoin@niftybox.net" <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" + <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 <thashiznets@yahoo.com.au> +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 + +<html><body><div style=3D"color:#000; background-color:#fff; font-family:He= +lvetica Neue-Light, Helvetica Neue Light, Helvetica Neue, Helvetica, Arial,= + Lucida Grande, Sans-Serif;font-size:16px"><div id=3D"yui_3_16_0_1_14261226= +60566_21977" dir=3D"ltr">Right you are!</div><div id=3D"yui_3_16_0_1_142612= +2660566_21954" dir=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1426122660566_= +21978" dir=3D"ltr">I saw Thomas's email about Electrum 2.0 not supporting B= +IP39.</div><div id=3D"yui_3_16_0_1_1426122660566_21952" dir=3D"ltr"><br></d= +iv><div id=3D"yui_3_16_0_1_1426122660566_21951" dir=3D"ltr">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.</div><div id=3D"yui_3_16_0= +_1_1426122660566_22047" dir=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_14261= +22660566_22046" dir=3D"ltr">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.</div><div id=3D"yui_3_16_0_1_1426122660566_21950" dir= +=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1426122660566_21964" dir=3D"ltr"= +>I think BIP39 is fantastic.</div><div id=3D"yui_3_16_0_1_1426122660566_219= +67" dir=3D"ltr"><br></div><div id=3D"yui_3_16_0_1_1426122660566_21968" dir= +=3D"ltr">I think Electrum 2.0 (And everyone) should use BIP39</div><di= +v id=3D"yui_3_16_0_1_1426122660566_21949"> </div><div id=3D"yui_3_16_= +0_1_1426122660566_21947">On 2015-03-11 06:21 PM, Thy Shizzle wrote:<br> +> 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<br> +> down to if a version was noted and the date. Assuming no date is<br> +> provided, it just means you are scanning the block chain from day 0 fo= +r<br> +> transactions right? Hardly a big deal as you will still recover funds = +right?<br> +<br> +Unfortunately there's more incompatibility than just the date issue:<br> +<br> +* seed: some follow BIP39, and some roll their own<br> +* HD structure: some follow BIP44, some BIP32 derivation, and some roll<br> +their own<br> +<br> +So actually very few wallets are seed-compatible, even ignoring the date<br= +> +question.<br> +<br> +> <br> +> 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= +<br> +> one extra word into the mnemonic to signify version, so if you have a = +12<br> +> word mnemonic then you have 12 words + 1 word version. Version 1 has n= +o<br> +> 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<br> +> 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<b= +r> +> word can simply be thrown on the end.<br> +<br> +That's a reasonable solution.<br> +<br> +> <br> +> So in summary I feel that date can be handled by assuming day 0, and<b= +r> +> version is not an issue yet but may become one and probably it is a go= +od<br> +> idea to think about standardising a version into BIP39, I have<br> +> provided a seed idea for discussion.<br> +> <br> +> I don't think it is quite the doom and gloom I'm reading :)<br> +> <br> +> <br> +> devrandom:<br> +> "I'd like to offer that the best practice for the shared wallet use ca= +se<br> +> should be multi-device multi-sig. The mobile has a key, the desk= +top has<br> +> a key and a third-party security oracle has a third key. The ora= +cle<br> +> would have different security thresholds for countersigning the mobile= +.<br> +> <br> +> This way you can have the same overall wallet on all devices, but<br> +> different security profiles on different keys.<br> +> <br> +> That said, I do agree that mnemonic phrases should be portable, and fi= +nd<br> +> it unfortunate that the ecosystem is failing to standardize on phrase<= +br> +> handling."<br> +<br> +-- <br> +devrandom / Miron</div></div></body></html> +------=_Part_4415281_641691130.1426127909992-- + + |