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-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1We09W-0000Dg-BJ
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Apr 2014 10:48:14 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.174 as permitted sender)
client-ip=209.85.216.174; envelope-from=tier.nolan@gmail.com;
helo=mail-qc0-f174.google.com;
Received: from mail-qc0-f174.google.com ([209.85.216.174])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1We09V-0005Zb-6W
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Apr 2014 10:48:14 +0000
Received: by mail-qc0-f174.google.com with SMTP id c9so5114146qcz.33
for <bitcoin-development@lists.sourceforge.net>;
Sat, 26 Apr 2014 03:48:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.224.20.72 with SMTP id e8mr18389707qab.86.1398509287729;
Sat, 26 Apr 2014 03:48:07 -0700 (PDT)
Received: by 10.140.25.86 with HTTP; Sat, 26 Apr 2014 03:48:07 -0700 (PDT)
In-Reply-To: <535B8C43.8030502@gmx.de>
References: <ljdd29$522$1@ger.gmane.org>
<1398437607.23028.110362141.03111A2A@webmail.messagingengine.com>
<CAAS2fgRiXdOBN2gVZ0Xh4kBeOKiS80AjD5+VxJEut9nWt-0WUg@mail.gmail.com>
<535B8C43.8030502@gmx.de>
Date: Sat, 26 Apr 2014 11:48:07 +0100
Message-ID: <CAE-z3OWcZdQ0J3vNYQ7whGHOZZzMh=wYKxCKtrf1i8VSseZArQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c1bfea4f6dd004f7efd1d5
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: 1We09V-0005Zb-6W
Subject: Re: [Bitcoin-development] BIP32 "wallet structure" in use? Remove
it?
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: Sat, 26 Apr 2014 10:48:14 -0000
--001a11c1bfea4f6dd004f7efd1d5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Maybe the solution is to have a defined way to import an unknown wallet?
This means that the gap space and a search ordering needs to be defined.
Given a blockchain and a root seed, it should be possible to find all the
addresses for that root seed.
The hierarchy that the wallet actually uses could be anything.
On Sat, Apr 26, 2014 at 11:36 AM, Thomas Voegtlin <thomasv1@gmx.de> wrote:
> I totally agree with gmaxwell here. The cost of interoperability is too
> high. It would force us to freeze all features, and to require a broad
> consensus everytime we want to add something new.
>
> In addition, some partial level of compatibility would probably lead to
> users not able to recover all their funds when they enter their seed in
> another wallet. That is not acceptable, and should be avoided.
>
>
>
>
> Le 25/04/2014 17:46, Gregory Maxwell a =C3=A9crit :
> >
> > I don't believe that wallet interoperability at this level is possible
> > in general except as an explicit compatibility feature. I also don't
> > believe that it is a huge loss that it is so.
> >
> > The structure of the derivation defines and constrains functionality.
> > You cannot be structure compatible unless you have the same features
> > and behavior with respect to key management. To that extent that
> > wallets have the same features, I agree its better if they are
> > compatible=E2=80=94 but unless they are dead software they likely won't=
keep
> > the same features for long.
> >
> > Even if their key management were compatible there are many other
> > things that go into making a wallet portable between systems; the
> > handling of private keys is just one part: a complete wallet will
> > have other (again, functionality specific) metadata.
> >
> > I agree that it would be it would be possible to support a
> > compatibility mode where a wallet has just a subset of features which
> > works when loaded into different systems, but I'm somewhat doubtful
> > that it would be widely used. The decision to use that mode comes at
> > the wrong time=E2=80=94 when you start, not when you need the features =
you
> > chose to disable or when you want to switch programs. But the obvious
> > thing to do there is to just specify that a linear chain with no
> > further branching is that mode: then that will be the same mode you
> > use when someone gives you a master public key and asks you to use it
> > for reoccurring changes=E2=80=94 so at least the software will get used=
.
> >
> > Compatibility for something like a recovery tool is another matter,
> > and BIP32 probably defines enough there that with a bit of extra data
> > about how the real wallet worked that recovery can be successful.
> >
> > Calling it "vendor lock in" sounds overblown to me. If someone wants
> > to change wallets they can transfer the funds=E2=80=94 manual handling =
of
> > private keys is seldom advisable, and as is they're going to lose
> > their metadata in any case. No one expects to switch banks and to
> > keep their account records at the new bank. And while less than
> > perfect, the price of heavily constraining functionality in order to
> > get another result is just too high.
> >
> >
> -------------------------------------------------------------------------=
-----
> > 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
> >
>
>
> -------------------------------------------------------------------------=
-----
> 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
>
--001a11c1bfea4f6dd004f7efd1d5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>Maybe the solution is to have a defined way to i=
mport an unknown wallet?<br><br>This means that the gap space and a search =
ordering needs to be defined.<br><br></div>Given a blockchain and a root se=
ed, it should be possible to find all the addresses for that root seed.<br>
<br></div>The hierarchy that the wallet actually uses could be anything.<br=
></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat=
, Apr 26, 2014 at 11:36 AM, Thomas Voegtlin <span dir=3D"ltr"><<a href=
=3D"mailto:thomasv1@gmx.de" target=3D"_blank">thomasv1@gmx.de</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">I totally agree with gmaxwell here. The cost=
of interoperability is too<br>
high. It would force us to freeze all features, and to require a broad<br>
consensus everytime we want to add something new.<br>
<br>
In addition, some partial level of compatibility would probably lead to<br>
users not able to recover all their funds when they enter their seed in<br>
another wallet. That is not acceptable, and should be avoided.<br>
<br>
<br>
<br>
<br>
Le 25/04/2014 17:46, Gregory Maxwell a =C3=A9crit :<br>
<div class=3D"HOEnZb"><div class=3D"h5">><br>
> I don't believe that wallet interoperability at this level is poss=
ible<br>
> in general except as an explicit compatibility feature. I also don'=
;t<br>
> believe that it is a huge loss that it is so.<br>
><br>
> The structure of the derivation defines and constrains functionality.<=
br>
> You cannot be structure compatible unless you have the same features<b=
r>
> and behavior with respect to key management. =C2=A0To that extent that=
<br>
> wallets have the same features, I agree its better if they are<br>
> compatible=E2=80=94 but unless they are dead software they likely won&=
#39;t keep<br>
> the same features for long.<br>
><br>
> Even if their key management were compatible there are many other<br>
> things that go into making a wallet portable between systems; the<br>
> handling of private keys is just one part: =C2=A0a complete wallet wil=
l<br>
> have other (again, functionality specific) metadata.<br>
><br>
> I agree that it would be it would be possible to support a<br>
> compatibility mode where a wallet has just a subset of features which<=
br>
> works when loaded into different systems, but I'm somewhat doubtfu=
l<br>
> that it would be widely used. The decision to use that mode comes at<b=
r>
> the wrong time=E2=80=94 when you start, not when you need the features=
you<br>
> chose to disable or when you want to switch programs. But the obvious<=
br>
> thing to do there is to just specify that a linear chain with no<br>
> further branching is that mode: then that will be the same mode you<br=
>
> use when someone gives you a master public key and asks you to use it<=
br>
> for reoccurring changes=E2=80=94 so at least the software will get use=
d.<br>
><br>
> Compatibility for something like a recovery tool is another matter,<br=
>
> and BIP32 probably defines enough there that with a bit of extra data<=
br>
> about how the real wallet worked that recovery can be successful.<br>
><br>
> Calling it "vendor lock in" sounds overblown to me. =C2=A0If=
someone wants<br>
> to change wallets they can transfer the funds=E2=80=94 manual handling=
of<br>
> private keys is seldom advisable, and as is they're going to lose<=
br>
> their metadata in any case. =C2=A0No one expects to switch banks and t=
o<br>
> keep their account records at the new bank. And while less than<br>
> perfect, the price of heavily constraining functionality in order to<b=
r>
> get another result is just too high.<br>
><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<b=
r>
> <a href=3D"http://p.sf.net/sfu/ExoPlatform" target=3D"_blank">http://p=
.sf.net/sfu/ExoPlatform</a><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>
---------------------------------------------------------------------------=
---<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>
_______________________________________________<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>
--001a11c1bfea4f6dd004f7efd1d5--
|
