1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
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--
|
