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
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WTADy-0003Wk-En
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Mar 2014 13:20:02 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.53 as permitted sender)
client-ip=209.85.219.53; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f53.google.com;
Received: from mail-oa0-f53.google.com ([209.85.219.53])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WTADw-0000Zk-3C
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Mar 2014 13:20:01 +0000
Received: by mail-oa0-f53.google.com with SMTP id j17so4290637oag.40
for <bitcoin-development@lists.sourceforge.net>;
Thu, 27 Mar 2014 06:19:54 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.132.236 with SMTP id ox12mr516020oeb.81.1395926394756;
Thu, 27 Mar 2014 06:19:54 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Thu, 27 Mar 2014 06:19:54 -0700 (PDT)
In-Reply-To: <CAHv+tb5gYKEtbwxwwBGWk-M98kGnjGw3ffNQAaLQz=hb8BTaDg@mail.gmail.com>
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
<53340999.807@gmx.de>
<CAJna-HhmFya+3W67qQt0wMhW=B4vJvwdkr-5WnU+KEaKq7uaUA@mail.gmail.com>
<5334144A.9040600@gmx.de>
<CANEZrP37dO53Jp2rXpPqO3eMd6AWamtXaReq0arMfC=uY2aFUA@mail.gmail.com>
<CANEZrP21X_Uk+_XWN6y2tgiup07Xd12bZZoFfnheG_Lz-ipbPQ@mail.gmail.com>
<CAHv+tb5gYKEtbwxwwBGWk-M98kGnjGw3ffNQAaLQz=hb8BTaDg@mail.gmail.com>
Date: Thu, 27 Mar 2014 14:19:54 +0100
X-Google-Sender-Auth: EdIdM8qiegRdqJ4orPFsRPeFL7o
Message-ID: <CANEZrP1F=cPrMevBd7sFrezWpL5BJ7b-ngJny0J7D19M7GgoNA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Thomas Kerin <thomas.kerin@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b41cd28e4665d04f5967089
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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
X-Headers-End: 1WTADw-0000Zk-3C
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New BIP32 structure
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
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, 27 Mar 2014 13:20:02 -0000
--047d7b41cd28e4665d04f5967089
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Obviously, SHA256 can't magically generate more entropy out of nothing, it
just stretches whatever is put in. If your seed was only 32 bits then
hashing wouldn't save you: every possible private key could easily be
calculated in advance.
On Thu, Mar 27, 2014 at 2:12 PM, Thomas Kerin <thomas.kerin@gmail.com>wrote=
:
> Isn't the length of the seed arbitrary anyway? Once decoded using whateve=
r
> mnemonic implementation (electrums, or BIP0039) the bytestream is
> immediately passed to HMAC-SHA256 to generate the master key. No matter
> what your initial entropy is, it would be hashed anyway.
>
>
> On Thu, Mar 27, 2014 at 12:49 PM, Mike Hearn <mike@plan99.net> wrote:
>
>> Ah, BIP32 allows for a range of entropy sizes and it so happens that the=
y
>> picked 256 bits instead of 128 bits.
>>
>> I'd have thought that there is a right answer for this. 2^128 should not
>> be brute forceable, and longer sizes have a cost in terms of making the
>> seeds harder to write down on paper. So should this be a degree of freed=
om?
>>
>>
>> On Thu, Mar 27, 2014 at 1:28 PM, Mike Hearn <mike@plan99.net> wrote:
>>
>>> By the way, I just noticed that greenaddress.it is creating seeds that
>>> have 24 words instead of 12. Does anyone know what's up with that? They
>>> claim to be using BIP32 wallets so I wanted to see if they were using t=
he
>>> default structure and if so, whether bitcoinj was compatible with it
>>> (before I switch to the one discussed here). But it seems we fall at th=
e
>>> first hurdle ...
>>>
>>>
>>> On Thu, Mar 27, 2014 at 1:06 PM, Thomas Voegtlin <thomasv1@gmx.de>wrote=
:
>>>
>>>>
>>>>
>>>> Le 27/03/2014 12:30, Marek Palatinus a =C3=A9crit :
>>>> > Ah, I forget to two things, which should be into the BIP as well:
>>>> >
>>>> > a) Gap factor for addresses; as Thomas mentioned, although some
>>>> software
>>>> > can watch almost unlimited amount of unused addresses, this is serio=
us
>>>> > concern for lightweight or server-based wallets like Electrum or
>>>> > myTREZOR. myTREZOR currently uses gap factor 10, which is (from my
>>>> > experience so far) quite sane for most of users.
>>>>
>>>>
>>>> Yes, I was planning to increase the number of available unused address=
es
>>>> to 10 or 20 in the bip32 version of Electrum.
>>>>
>>>> Related to this, here is another idea I would like to submit:
>>>>
>>>> Instead of using a "gap limit" (maximal number of consecutive unused
>>>> addresses), I think we should get rid of the topology, and simply coun=
t
>>>> the number of unused addresses since the beginning of the sequence.
>>>> Indeed, the topology of the sequence of addresses is of no interest to
>>>> the user. Users often misinterpret "gap limit" as the "number of unuse=
d
>>>> addresses available", so I think we should just give them what they wa=
nt
>>>> :) This is easier to understand, and it makes things more predictable,
>>>> because the wallet will always display the same number of unused
>>>> addresses (except when it is waiting for confirmations).
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------=
--------
>>>> _______________________________________________
>>>> Bitcoin-development mailing list
>>>> Bitcoin-development@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------=
------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
--047d7b41cd28e4665d04f5967089
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Obviously, SHA256 can't magically generate more entrop=
y out of nothing, it just stretches whatever is put in. If your seed was on=
ly 32 bits then hashing wouldn't save you: every possible private key c=
ould easily be calculated in advance.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Mar 2=
7, 2014 at 2:12 PM, Thomas Kerin <span dir=3D"ltr"><<a href=3D"mailto:th=
omas.kerin@gmail.com" target=3D"_blank">thomas.kerin@gmail.com</a>></spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Isn't the length o=
f the seed arbitrary anyway? Once decoded using whatever mnemonic implement=
ation (electrums, or BIP0039) the bytestream is immediately passed to HMAC-=
SHA256 to generate the master key. No matter what your initial entropy is, =
it would be hashed anyway.<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote">On Thu, Mar 27, 2014 at 12:49 PM, Mi=
ke Hearn <span dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D=
"_blank">mike@plan99.net</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Ah, BIP32 allows for a rang=
e of entropy sizes and it so happens that they picked 256 bits instead of 1=
28 bits.<div>
<br></div><div>I'd have thought that there is a right answer for this. =
2^128 should not be brute forceable, and longer sizes have a cost in terms =
of making the seeds harder to write down on paper. So should this be a degr=
ee of freedom?</div>
</div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=
e">On Thu, Mar 27, 2014 at 1:28 PM, Mike Hearn <span dir=3D"ltr"><<a hre=
f=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>></spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr">By the way, I just noticed that <a href=3D"http://greenadd=
ress.it" target=3D"_blank">greenaddress.it</a> is creating seeds that have =
24 words instead of 12. Does anyone know what's up with that? They clai=
m to be using BIP32 wallets so I wanted to see if they were using the defau=
lt structure and if so, whether bitcoinj was compatible with it (before I s=
witch to the one discussed here). But it seems we fall at the first hurdle =
...</div>
<div><div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Mar 2=
7, 2014 at 1:06 PM, Thomas Voegtlin <span dir=3D"ltr"><<a href=3D"mailto=
:thomasv1@gmx.de" target=3D"_blank">thomasv1@gmx.de</a>></span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<br>
<br>
Le 27/03/2014 12:30, Marek Palatinus a =C3=A9crit :<br>
> Ah, I forget to two things, which should be into the BIP as well:<br>
><br>
> a) Gap factor for addresses; as Thomas mentioned, although some softwa=
re<br>
> can watch almost unlimited amount of unused addresses, this is serious=
<br>
> concern for lightweight or server-based wallets like Electrum or<br>
> myTREZOR. myTREZOR currently uses gap factor 10, which is (from my<br>
> experience so far) quite sane for most of users.<br>
<br>
<br>
Yes, I was planning to increase the number of available unused addresses<br=
>
to 10 or 20 in the bip32 version of Electrum.<br>
<br>
Related to this, here is another idea I would like to submit:<br>
<br>
Instead of using a "gap limit" (maximal number of consecutive unu=
sed<br>
addresses), I think we should get rid of the topology, and simply count<br>
the number of unused addresses since the beginning of the sequence.<br>
Indeed, the topology of the sequence of addresses is of no interest to<br>
the user. Users often misinterpret "gap limit" as the "numbe=
r of unused<br>
addresses available", so I think we should just give them what they wa=
nt<br>
:) This is easier to understand, and it makes things more predictable,<br>
because the wallet will always display the same number of unused<br>
addresses (except when it is waiting for confirmations).<br>
<div><div><br>
<br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>-----------------------------------------------------------=
-------------------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
--047d7b41cd28e4665d04f5967089--
|
