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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WTBAf-0001At-16
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Mar 2014 14:20:41 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.169 as permitted sender)
client-ip=209.85.214.169; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f169.google.com;
Received: from mail-ob0-f169.google.com ([209.85.214.169])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WTBAc-0005zw-Gh
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Mar 2014 14:20:40 +0000
Received: by mail-ob0-f169.google.com with SMTP id va2so4285487obc.14
for <bitcoin-development@lists.sourceforge.net>;
Thu, 27 Mar 2014 07:20:33 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.174.170 with SMTP id bt10mr1658799oec.47.1395930032935;
Thu, 27 Mar 2014 07:20:32 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Thu, 27 Mar 2014 07:20:32 -0700 (PDT)
In-Reply-To: <1395928699.5369.99593201.1CFF9238@webmail.messagingengine.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>
<53342C6C.2060006@gmx.de>
<1395928699.5369.99593201.1CFF9238@webmail.messagingengine.com>
Date: Thu, 27 Mar 2014 15:20:32 +0100
X-Google-Sender-Auth: DFTpZ67KtFdDJUuuqZpG6_H1dgU
Message-ID: <CANEZrP22Ta7LEgjNLjufs5skA1RaSB+mivqcMHj0iJBNNjZL3Q@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jim <jim618@fastmail.co.uk>
Content-Type: multipart/alternative; boundary=047d7bd6c52cbe9b7304f59749e8
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: 1WTBAc-0005zw-Gh
Cc: Bitcoin Dev <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 14:20:41 -0000
--047d7bd6c52cbe9b7304f59749e8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
For SPV wallets it's more complicated. There must always be a large
lookahead window for latency reasons. We can't query the entire database
because we don't know how far ahead the user is. So we have to assume there
might be a lot of transaction traffic and create a large window, to reduce
the chances that we run out whilst syncing and have to abort/restart the
sync after resetting the Bloom filter.
If you have a full db index then you can calculate some addresses, query,
if they all get hits, calculate some more, requery, etc. It's a bit simpler=
.
On Thu, Mar 27, 2014 at 2:58 PM, Jim <jim618@fastmail.co.uk> wrote:
> Good to hear the bip32 wallet structure is _so_ close to being
> standardised.
> For MultiBit HD, we have put in support for 12/18/24 words but have the U=
I
> 'suggest' to use 12.
> You can see this on the wallet creation wizard Gary recently blogged abou=
t:
> https://multibit.org/blog/2014/03/26/multibit-hd-welcome-wizard.html
>
> There's a little combo for the seed length, with 12 as the default.
>
>
> @Thomas. You mention gaps. We are creating new addresses on the UI in a
> panel marked 'Request' where the user also types in a QR code label and a
> note to themselves. This gets stored away as a first class
> 'PaymentRequest'. The UI 'suggests' that each address is used once. There
> will be some gaps (where the payment request is never paid) but we aren't
> bulk creating addresses. I am hoping this shouldn't cause Electrum a
> problem.
>
> We are also storing a timestamp (the number of days since the genesis
> block) to help wallet restore but that is SPV specific.
>
>
> On Thu, Mar 27, 2014, at 01:49 PM, Thomas Voegtlin wrote:
> >
> >
> > Le 27/03/2014 13:49, Mike Hearn a =C3=A9crit :
> IP32 allows for a range of entropy sizes and it so happens that
> > > they 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 t=
he
> > > seeds harder to write down on paper. So should this be a degree of
> freedom?
> > >
> >
> >
> > Here is what I understand:
> >
> > 2^128 iterations is not brute forcable today, and will not be for the
> > foreseeable future.
> >
> > An EC pubkey of length n can be forced in approximately 2^(n/2)
> > iterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, whic=
h
> > are 256 bits, would require 2^128 iterations. This is why unused
> > addresses (160 bits hash) are better protected than already used ones.
> >
> > However, people tend to believe that a public key of size n requires 2^=
n
> > iterations. This belief might have been spread by this popular image:
> > https://bitcointalk.org/index.php?topic=3D508880.msg5616146#msg5616146
> >
> >
> >
> -------------------------------------------------------------------------=
-----
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> --
> http://bitcoin-solutions.co.uk
>
>
> -------------------------------------------------------------------------=
-----
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--047d7bd6c52cbe9b7304f59749e8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">For SPV wallets it's more complicated. There must alwa=
ys be a large lookahead window for latency reasons. We can't query the =
entire database because we don't know how far ahead the user is. So we =
have to assume there might be a lot of transaction traffic and create a lar=
ge window, to reduce the chances that we run out whilst syncing and have to=
abort/restart the sync after resetting the Bloom filter.<div>
<br></div><div>If you have a full db index then you can calculate some addr=
esses, query, if they all get hits, calculate some more, requery, etc. It&#=
39;s a bit simpler.</div></div><div class=3D"gmail_extra"><br><br><div clas=
s=3D"gmail_quote">
On Thu, Mar 27, 2014 at 2:58 PM, Jim <span dir=3D"ltr"><<a href=3D"mailt=
o:jim618@fastmail.co.uk" target=3D"_blank">jim618@fastmail.co.uk</a>></s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
Good to hear the bip32 wallet structure is _so_ close to being standardised=
.<br>
For MultiBit HD, we have put in support for 12/18/24 words but have the UI =
'suggest' to use 12.<br>
You can see this on the wallet creation wizard Gary recently blogged about:=
<br>
<a href=3D"https://multibit.org/blog/2014/03/26/multibit-hd-welcome-wizard.=
html" target=3D"_blank">https://multibit.org/blog/2014/03/26/multibit-hd-we=
lcome-wizard.html</a><br>
<br>
There's a little combo for the seed length, with 12 as the default.<br>
<br>
<br>
@Thomas. You mention gaps. We are creating new addresses on the UI in a pan=
el marked 'Request' where the user also types in a QR code label an=
d a note to themselves. This gets stored away as a first class 'Payment=
Request'. The UI 'suggests' that each address is used once. The=
re will be some gaps (where the payment request is never paid) but we aren&=
#39;t bulk creating addresses. I am hoping this shouldn't cause Electru=
m a problem.<br>
<br>
We are also storing a timestamp (the number of days since the genesis block=
) to help wallet restore but that is SPV specific.<br>
<div class=3D"im HOEnZb"><br>
<br>
On Thu, Mar 27, 2014, at 01:49 PM, Thomas Voegtlin wrote:<br>
><br>
><br>
> Le 27/03/2014 13:49, Mike Hearn a =C3=A9crit :<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">IP32 allows for a range of en=
tropy sizes and it so happens that<br>
> > they picked 256 bits instead of 128 bits.<br>
> ><br>
> > I'd have thought that there is a right answer for this. 2^128=
should not<br>
> > be brute forceable, and longer sizes have a cost in terms of maki=
ng the<br>
> > seeds harder to write down on paper. So should this be a degree o=
f freedom?<br>
> ><br>
><br>
><br>
> Here is what I understand:<br>
><br>
> 2^128 iterations is not brute forcable today, and will not be for the<=
br>
> foreseeable future.<br>
><br>
> An EC pubkey of length n can be forced in approximately 2^(n/2)<br>
> iterations (see <a href=3D"http://ecc-challenge.info/" target=3D"_blan=
k">http://ecc-challenge.info/</a>) Thus, Bitcoin pubkeys, which<br>
> are 256 bits, would require 2^128 iterations. This is why unused<br>
> addresses (160 bits hash) are better protected than already used ones.=
<br>
><br>
> However, people tend to believe that a public key of size n requires 2=
^n<br>
> iterations. This belief might have been spread by this popular image:<=
br>
> <a href=3D"https://bitcointalk.org/index.php?topic=3D508880.msg5616146=
#msg5616146" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D50=
8880.msg5616146#msg5616146</a><br>
><br>
><br>
> ----------------------------------------------------------------------=
--------<br>
> _______________________________________________<br>
> Bitcoin-development mailing list<br>
> <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
> <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
<br>
<br>
</div></div><span class=3D"HOEnZb"><font color=3D"#888888">--<br>
<a href=3D"http://bitcoin-solutions.co.uk" target=3D"_blank">http://bitcoin=
-solutions.co.uk</a><br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@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>
--047d7bd6c52cbe9b7304f59749e8--
|
