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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1Wd25D-00006y-HP
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 18:39:47 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.42 as permitted sender)
client-ip=209.85.216.42; envelope-from=tier.nolan@gmail.com;
helo=mail-qa0-f42.google.com;
Received: from mail-qa0-f42.google.com ([209.85.216.42])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wd25C-0007sD-BB
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 18:39:47 +0000
Received: by mail-qa0-f42.google.com with SMTP id k15so1254643qaq.15
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Apr 2014 11:39:40 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.224.163.73 with SMTP id z9mr23730174qax.90.1398278380857;
Wed, 23 Apr 2014 11:39:40 -0700 (PDT)
Received: by 10.140.25.86 with HTTP; Wed, 23 Apr 2014 11:39:40 -0700 (PDT)
In-Reply-To: <CAJna-Hh2t-E=fm9V0EH+qOQTx+qsmcBemEJmML0G9PgsrJr5eg@mail.gmail.com>
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
<F2C8C044-EF92-4CCE-9235-28CA7FCE3526@bitsofproof.com>
<CAJHLa0PPAsBLgsy0vgPpUp=UzeR_fWUEzFb5+xtmODEk4MGPVQ@mail.gmail.com>
<CAJfRnm7V6fgcj=TMfa2ZTYWOKtE5aoUT1xnVtKUSyriB=6cagQ@mail.gmail.com>
<CAPg+sBjwf1TcK1CGKVKFzYbV-78j8t-pav7=PEgG7Yqi6-yE7A@mail.gmail.com>
<53344FF8.7030204@gk2.sk>
<CAPg+sBhbx5vy_hewAkFPaiXHzSMNH0qLhEYGjPmQMjR5StP-tw@mail.gmail.com>
<CAJna-Hi0JnrF2_rUx0rGkdnsuCoaD01e3Gobpn+QqbL=D1Uivg@mail.gmail.com>
<CAJna-HirtsGLfAhfUf9dAYEGWo6g=o=eAU187c2pdW8vDFGkPw@mail.gmail.com>
<CAPg+sBg8wDH9yTUoyhRbuzVtbD8hGxya8tOnV4pMToHy3gLrzw@mail.gmail.com>
<CAJna-HiN_1KQmpDJFFX6mGvM63RC0xwXxvfuorpihnzYf4=fsQ@mail.gmail.com>
<CAJna-HgfpyHX_0AHwt1Hkj0qhD_-xOcpxsZ9KXq=7CPgwse1hA@mail.gmail.com>
<CAPg+sBguSQ8dk1xXKinX+ez4BmdM3sz-huruuhD6NCTsp0kRBQ@mail.gmail.com>
<CAJna-Hib6umrkG0pAQzQvsyBMxOU6P675TURsVuWSU_ci9+X_A@mail.gmail.com>
<CAPg+sBiwzfXDAM0FKsBPi8d6E5y_nK5FDyfPvPhOTAA+f8654Q@mail.gmail.com>
<CAJna-HhPm0U2odPgRji7zJqCZCWuXKT_=ayC2tsajjRX5TiCXg@mail.gmail.com>
<CAJna-Hh2t-E=fm9V0EH+qOQTx+qsmcBemEJmML0G9PgsrJr5eg@mail.gmail.com>
Date: Wed, 23 Apr 2014 19:39:40 +0100
Message-ID: <CAE-z3OVCL34FMECHDC3d8OiRKYhVSkzZFU0cGHV0ifu09bCbJA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e0158b030302fa904f7ba0e7b
X-Spam-Score: -0.6 (/)
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
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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
X-Headers-End: 1Wd25C-0007sD-BB
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: Wed, 23 Apr 2014 18:39:47 -0000
--089e0158b030302fa904f7ba0e7b
Content-Type: text/plain; charset=UTF-8
Different users could have different gap limit requirements. 20 seems very
low as the default.
A merchant could easily send 20 addresses in a row to customers and none of
them bother to actually buy anything.
Setting the gap limit to high is just a small extra cost in that case.
Bip-32 serialization doesn't have a way of adding meta data though.
On Wed, Apr 23, 2014 at 7:18 PM, slush <slush@centrum.cz> wrote:
> For those who don't follow github pull requests regularly; there's pull
> request for BIP64 defining HD wallet structure as discussed in this thread:
>
> https://github.com/bitcoin/bips/pull/52
>
>
>
> On Wed, Apr 23, 2014 at 8:01 PM, slush <slush@centrum.cz> wrote:
>
>>
>>
>>
>> On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille <pieter.wuille@gmail.com>wrote:
>>>
>>> Storing the seed is superior to storing the master node already
>>> (whether coin specific or not), as it is smaller.
>>>
>>>
>> ...Except that you're loosing flexibility (serialization,
>> deserialization) which gives you BIP32 node.
>>
>> I see "bip32 seed" as some transitional, internal state from raw entropy
>> to bip32 master node and this seed should not be handled by the end user in
>> any form. In the oposite, well-serialized bip32 node (in xpriv, or even in
>> mnemonic format) can be used very widely and have no downsides against
>> using raw "bip32 seed".
>>
>>
>>>
>>> Fair enough, it would break strictly BIP32. Then again, BIP32 is a
>>> *Bitcoin* improvement proposal, and not something that necessarily
>>> applies to other coins (they can adopt it of course, I don't care).
>>>
>>>
>> I also don't care too much about altcoins, but people want them so me, as
>> infrastructure developer, need to think about it. And I don't see any
>> reason for breaking compatibility between Bitcoin and other altcoins. I
>> would be happier if there will be another sentence than "Bitcoin seed", but
>> honestly, who cares. It is just some magic string for hashing the raw
>> seed...
>>
>>
>>> What I dislike is that this removes the ability of using the magic in
>>> the serialization to prevent importing a chain from the wrong coin.
>>>
>>
>> The truth is that even existing software which handle bip32 don't care
>> about 'version' at all. I think that "xpub/xprv" distinction is the only
>> useful feature of version, so user se if it stores public or private
>> information.
>>
>> But using prefixes which doesn't enforce anything is even more dangerous.
>> If somebody exports node "dogeblablabla", it creates false exceptations
>> that there's only dogecoin stored.
>>
>> Marek
>>
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--089e0158b030302fa904f7ba0e7b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Different users could have different gap limit requir=
ements.=C2=A0 20 seems very low as the default.<br><br>A merchant could eas=
ily send 20 addresses in a row to customers and none of them bother to actu=
ally buy anything.<br>
<br></div><div>Setting the gap limit to high is just a small extra cost in =
that case.<br></div><div><br></div>Bip-32 serialization doesn't have a =
way of adding meta data though.</div><div class=3D"gmail_extra"><br><br><di=
v class=3D"gmail_quote">
On Wed, Apr 23, 2014 at 7:18 PM, slush <span dir=3D"ltr"><<a href=3D"mai=
lto:slush@centrum.cz" target=3D"_blank">slush@centrum.cz</a>></span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">For those who don't follow github pull requests regula=
rly; there's pull request for BIP64 defining HD wallet structure as dis=
cussed in this thread:<div><br></div><div><a href=3D"https://github.com/bit=
coin/bips/pull/52" target=3D"_blank">https://github.com/bitcoin/bips/pull/5=
2</a><br>
</div><div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5"><div cla=
ss=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Apr 23, 2014 =
at 8:01 PM, slush <span dir=3D"ltr"><<a href=3D"mailto:slush@centrum.cz"=
target=3D"_blank">slush@centrum.cz</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"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div>On Wed, Apr 23, 2014 at 7:42 PM=
, Pieter Wuille <span dir=3D"ltr"><<a href=3D"mailto:pieter.wuille@gmail=
.com" target=3D"_blank">pieter.wuille@gmail.com</a>></span> wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex">
Storing the seed is superior to storing the master node already<br>
(whether coin specific or not), as it is smaller.<br>
<br></blockquote><div><br></div></div><div>...Except that you're loosin=
g flexibility (serialization, deserialization) which gives you BIP32 node.<=
/div><div><br></div><div>I see "bip32 seed" as some transitional,=
internal state from raw entropy to bip32 master node and this seed should =
not be handled by the end user in any form. In the oposite, well-serialized=
bip32 node (in xpriv, or even in mnemonic format) can be used very widely =
and have no downsides against using raw "bip32 seed".</div>
<div>
<div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
</div>Fair enough, it would break strictly BIP32. Then again, BIP32 is a<br=
>
*Bitcoin* improvement proposal, and not something that necessarily<br>
applies to other coins (they can adopt it of course, I don't care).<br>
<br></blockquote><div><br></div></div><div>I also don't care too much a=
bout altcoins, but people want them so me, as infrastructure developer, nee=
d to think about it. And I don't see any reason for breaking compatibil=
ity between Bitcoin and other altcoins. I would be happier if there will be=
another sentence than "Bitcoin seed", but honestly, who cares. I=
t is just some magic string for hashing the raw seed...</div>
<div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
What I dislike is that this removes the ability of using the magic in<br>
the serialization to prevent importing a chain from the wrong coin.<br></bl=
ockquote><div><br></div></div><div>The truth is that even existing software=
which handle bip32 don't care about 'version' at all. I think =
that "xpub/xprv" distinction is the only useful feature of versio=
n, so user se if it stores public or private information.</div>
<div><br></div><div>But using prefixes which doesn't enforce anything i=
s even more dangerous. If somebody exports node "dogeblablabla", =
it creates false exceptations that there's only dogecoin stored.</div>
<div><br></div><div>=C2=A0Marek</div></div></div></div>
</blockquote></div><br></div>
</div></div><br>-----------------------------------------------------------=
-------------------<br>
Start Your Social Network Today - Download eXo Platform<br>
Build your Enterprise Intranet with eXo Platform Software<br>
Java Based Open Source Intranet - Social, Extensible, Cloud Ready<br>
Get Started Now And Turn Your Intranet Into A Collaboration Platform<br>
<a href=3D"http://p.sf.net/sfu/ExoPlatform" target=3D"_blank">http://p.sf.n=
et/sfu/ExoPlatform</a><br>_______________________________________________<b=
r>
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>
<br></blockquote></div><br></div>
--089e0158b030302fa904f7ba0e7b--
|
