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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <marek@palatinus.cz>) id 1WXYEX-0001av-Sm
for bitcoin-development@lists.sourceforge.net;
Tue, 08 Apr 2014 15:46:45 +0000
X-ACL-Warn:
Received: from mail-ve0-f170.google.com ([209.85.128.170])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WXYES-0000gG-6L
for bitcoin-development@lists.sourceforge.net;
Tue, 08 Apr 2014 15:46:45 +0000
Received: by mail-ve0-f170.google.com with SMTP id pa12so955016veb.29
for <bitcoin-development@lists.sourceforge.net>;
Tue, 08 Apr 2014 08:46:34 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc:content-type;
bh=EHgc+msymCHdIHBn8n9VIUcAkBL3f8djg4OIcQxeZ4A=;
b=DoF33AtyWVYVDNzfswD+UnzA3wfyqidFXG2+nwv9H+qug/d2V/VVSPoIS3jybBLkyy
P3OArVgNy4Y9AEzcLEPGLnYiZ0SFFt8kvI1GtZvxtP3rgJha27O452jG604WjGJghKqM
87i1yhuMp+NbvR4BI4e3sP6WsRDZvlC2Cw8FNYzXrsY4kIofM6tQvuIB6auTM4ss026a
abSXQzlaIksgNjjqjVVh0koFBmNFMhEcxl44EunvpXXg6LQQSp/qPrCo9VElw2Cr74en
a4LrHCVY/PWyKWW3VvNUbLYSjYTC1ugvLqkuXgFD+yv/zl68KiJEZduok97baO0k2KiQ
ZYmg==
X-Gm-Message-State: ALoCoQneR80wALPhvV+Dnqri5NagP0CaaNUz3ZLR856kevEM8b3lEt5+1CXuMt9VfnlMrDbJcub3
X-Received: by 10.220.163.3 with SMTP id y3mr3822528vcx.7.1396971994604; Tue,
08 Apr 2014 08:46:34 -0700 (PDT)
MIME-Version: 1.0
Sender: marek@palatinus.cz
Received: by 10.58.234.100 with HTTP; Tue, 8 Apr 2014 08:46:04 -0700 (PDT)
In-Reply-To: <li12a7$i8o$1@ger.gmane.org>
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>
<li12a7$i8o$1@ger.gmane.org>
From: slush <slush@centrum.cz>
Date: Tue, 8 Apr 2014 17:46:04 +0200
X-Google-Sender-Auth: JSoVyBMYO42wGZxAw0huFYOjuLg
Message-ID: <CAJna-HgVs1ahhNKswaKPudwc1AvrBGgdfbZwNCvUPHFzHbh1WA@mail.gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=001a1133da667fef5704f689e38e
X-Spam-Score: 1.0 (+)
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
(slush[at]centrum.cz)
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1WXYES-0000gG-6L
Cc: "bitcoin-development@lists.sourceforge.net"
<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: Tue, 08 Apr 2014 15:46:46 -0000
--001a1133da667fef5704f689e38e
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Apr 8, 2014 at 4:49 PM, Andreas Schildbach <andreas@schildbach.de>wrote:
> While there is an agreement that a standard would be useful for sharing
> wallets, we certainly didn't agree on every aspect of a standard. At
> least not on this thread, and also not at the Berlin meeting.
>
>
We're going to write down BIP describing such structure. If any wallet want
to be BIP XX compatible, then it has chance to. Of course if any wallet
want to use another format, then it cannot call itself BIP XX compatible,
thus nobody will expect that such software will see/recover all keys
generated by BIP XX wallet.
> I understand each client will implement things a little bit different,
> for example the current plan is bitcoinj will hold all keys in memory
> and start reusing keys on low resources. Electrum uses a chain for their
> private purpose. Etc.
>
>
It still doesn't mean that bitcoinj or Electrum cannot share the bare
minimum of BIP XX. Of course if somebody will use Electrum for 2to3
transactions and then move wallet to client which does not offer such
feature, it won't work. But I don't see that as a problem.
> If we cannot 100% agree on a standard and also agree it will not be
> extended in future, I think we should not even try. It's dangerous for
> the money of users.
If some developers agree on some specific BIP, then it should be cross
compatible. Of course if somebody implements BIP XX in different way, then
it isn't BIP XX compatible.
>
>
I propose we keep our chains deliberately separate and only try
> standardizing after each of us has a feel for the specific requirements.
>
Of course, if somebody don't want to generate compatible bip32 paths, no
problem. It will be the same situation as now.
Marek
--001a1133da667fef5704f689e38e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Apr 8, 2014 at 4:49 PM, Andreas Schildbach <span dir=3D"ltr=
"><<a href=3D"mailto:andreas@schildbach.de" target=3D"_blank">andreas@sc=
hildbach.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"><div class=3D"">While there is an agreement =
that a standard would be useful for sharing<br></div>
wallets, we certainly didn't agree on every aspect of a standard. At<br=
>
least not on this thread, and also not at the Berlin meeting.<br>
<br></blockquote><div><br></div><div>We're going to write down BIP desc=
ribing such structure. If any wallet want to be BIP XX compatible, then it =
has chance to. Of course if any wallet want to use another format, then it =
cannot call itself BIP XX compatible, thus nobody will expect that such sof=
tware will see/recover all keys generated by BIP XX wallet.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
I understand each client will implement things a little bit different,<br>
for example the current plan is bitcoinj will hold all keys in memory<br>
and start reusing keys on low resources. Electrum uses a chain for their<br=
>
private purpose. Etc.<br>
<br></blockquote><div><br></div><div>It still doesn't mean that bitcoin=
j or Electrum cannot share the bare minimum of BIP XX. Of course if somebod=
y will use Electrum for 2to3 transactions and then move wallet to client wh=
ich does not offer such feature, it won't work. But I don't see tha=
t as a problem.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">
If we cannot 100% agree on a standard and also agree it will not be<br>
extended in future, I think we should not even try. It's dangerous for<=
br>
the money of users.</blockquote><div><br></div><div>If some developers agre=
e on some specific BIP, then it should be cross compatible. =A0Of course if=
somebody implements BIP XX in different way, then it isn't BIP XX comp=
atible.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">=A0<br></blockquote><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
I propose we keep our chains deliberately separate and only try<br>
standardizing after each of us has a feel for the specific requirements.<br=
>
<div class=3D"im HOEnZb"><span style=3D"color:rgb(34,34,34)"></span></div><=
/blockquote><div><br></div><div>Of course, if somebody don't want to ge=
nerate compatible bip32 paths, no problem. It will be the same situation as=
now.</div>
<div><br></div><div>Marek</div></div></div></div>
--001a1133da667fef5704f689e38e--
|
