summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorThy Shizzle <thashiznets@yahoo.com.au>2015-03-12 02:38:29 +0000
committerbitcoindev <bitcoindev@gnusha.org>2015-03-12 02:38:37 +0000
commitb82833c00025861a48563fbde0d4f23c9d73cbe3 (patch)
treed9f395ff71d8258ee47effbd8df045485303af4b
parent2fd61ad75dd6f0541416713eaa789cd3e000b248 (diff)
downloadpi-bitcoindev-b82833c00025861a48563fbde0d4f23c9d73cbe3.tar.gz
pi-bitcoindev-b82833c00025861a48563fbde0d4f23c9d73cbe3.zip
Re: [Bitcoin-development] Electrum 2.0 has been tagged
-rw-r--r--c8/258a2b67c6e7a8d59d36bee8d45061508830ec241
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)&nbsp;should use BIP39</div><di=
+v id=3D"yui_3_16_0_1_1426122660566_21949">&nbsp; </div><div id=3D"yui_3_16_=
+0_1_1426122660566_21947">On 2015-03-11 06:21 PM, Thy Shizzle wrote:<br>
+&gt; Hmmmm I don't think it's fair to say that there has been a failure to<=
+br>
+&gt; standardise. From what I read earlier among the wallets, mostly it cam=
+e<br>
+&gt; down to if a version was noted and the date. Assuming no date is<br>
+&gt; provided, it just means you are scanning the block chain from day 0 fo=
+r<br>
+&gt; 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>
+&gt; <br>
+&gt; Version right now is irrelevant as there is only one version of BIP39<=
+br>
+&gt; currently, probably this will change as 2048 iterations of HMACSHA512<=
+br>
+&gt; will likely need to be up scaled in the future, I thought about adding=
+<br>
+&gt; one extra word into the mnemonic to signify version, so if you have a =
+12<br>
+&gt; word mnemonic then you have 12 words + 1 word version. Version 1 has n=
+o<br>
+&gt; extra word, version 2 uses the first word on the list, version 3 uses<=
+br>
+&gt; the second word on the wordlist, so on and so forth. Least that's what=
+ I<br>
+&gt; was thinking of doing if I ever had to record a version, won't effect<=
+br>
+&gt; anything because entropy increases in blocks of 3 words so one extra<b=
+r>
+&gt; word can simply be thrown on the end.<br>
+<br>
+That's a reasonable solution.<br>
+<br>
+&gt; <br>
+&gt; So in summary I feel that date can be handled by assuming day 0, and<b=
+r>
+&gt; version is not an issue yet but may become one and probably it is a go=
+od<br>
+&gt; idea to think about standardising a version into BIP39, I have<br>
+&gt; provided a seed idea for discussion.<br>
+&gt; <br>
+&gt; I don't think it is quite the doom and gloom I'm reading :)<br>
+&gt; <br>
+&gt; <br>
+&gt; devrandom:<br>
+&gt; "I'd like to offer that the best practice for the shared wallet use ca=
+se<br>
+&gt; should be multi-device multi-sig.&nbsp; The mobile has a key, the desk=
+top has<br>
+&gt; a key and a third-party security oracle has a third key.&nbsp; The ora=
+cle<br>
+&gt; would have different security thresholds for countersigning the mobile=
+.<br>
+&gt; <br>
+&gt; This way you can have the same overall wallet on all devices, but<br>
+&gt; different security profiles on different keys.<br>
+&gt; <br>
+&gt; That said, I do agree that mnemonic phrases should be portable, and fi=
+nd<br>
+&gt; it unfortunate that the ecosystem is failing to standardize on phrase<=
+br>
+&gt; handling."<br>
+<br>
+-- <br>
+devrandom / Miron</div></div></body></html>
+------=_Part_4415281_641691130.1426127909992--
+
+