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
|
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 <mh.in.england@gmail.com>) id 1WdEis-0008F0-2X
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 08:09:34 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.49 as permitted sender)
client-ip=209.85.219.49; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f49.google.com;
Received: from mail-oa0-f49.google.com ([209.85.219.49])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WdEiq-0001XW-8x
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 08:09:34 +0000
Received: by mail-oa0-f49.google.com with SMTP id o6so2223334oag.8
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 Apr 2014 01:09:27 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.27.133 with SMTP id t5mr229074obg.65.1398326966935; Thu,
24 Apr 2014 01:09:26 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Thu, 24 Apr 2014 01:09:26 -0700 (PDT)
In-Reply-To: <CAPg+sBj68d5ZBDZ4uWvQYHMeq=bwTCaMNbwxfWGVL5MPh=7g2g@mail.gmail.com>
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
<CAE-z3OUMp_uO07+_R_x2yRLbSCzK1J5isbVUYEY3KF4Tx16K2Q@mail.gmail.com>
<53581480.5060103@gk2.sk> <201404231944.14256.luke@dashjr.org>
<5358B51F.8010202@gmx.de>
<CAPg+sBj68d5ZBDZ4uWvQYHMeq=bwTCaMNbwxfWGVL5MPh=7g2g@mail.gmail.com>
Date: Thu, 24 Apr 2014 10:09:26 +0200
X-Google-Sender-Auth: CMocafwVrtaFmZtVLTBEJWfFnV8
Message-ID: <CANEZrP19rdDmsCM17-GADyWajxXy8_AeBY-6et0nzG_EMXe2jg@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a113356c624e6ee04f7c55ea6
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: 1WdEiq-0001XW-8x
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, 24 Apr 2014 08:09:34 -0000
--001a113356c624e6ee04f7c55ea6
Content-Type: text/plain; charset=UTF-8
Right. So part of this is my fault, I'm afraid, because I do not intend to
implement any kind of subwallet/account support in bitcoinj. My reasons are:
1. The bitcoinj API already lets you create and use multiple wallets.
What's more, because of the desire to do key rotation (think rotating a
previously unencrypted wallet to an encrypted one that is stored on SSD's
that cannot reliably erase data), a bitcoinj wallet can actually contain
multiple BIP32 seeds and hierarchies at once, although only the last one
will be used for vending addresses. So adding subwallet support onto this
makes it even more complicated.
2. If there was a much better user experience to be enabled by this, it
may be worth it, but I believe many people will find subwallets rather
confusing. They don't match the analogy of bank accounts in several ways.
For instance, transferring money across them leaks private data and costs
miners fees, neither of which are true with banks.
Also it differs in a more important way. People have different bank
accounts because those accounts implement different policies. Current
accounts may pay a lower interest rate than savings accounts, but have
different features, and accounts can be used as security boundaries i.e. no
card withdrawals from savings. But "subwallets" are not like this. The only
justification for their existence is to avoid outputs being merged together
to make payments - a subtle technical detail of the protocol that users are
ill equipped to understand. If someone asked me "why should I create a
second account" I would be unable to give them a satisfying answer without
first teaching them about how the Bitcoin protocol works and the privacy
implications of that, which is practically a lecture sized topic.
3. MultiBit did support multiple wallets for a long time (just by
creating multiple wallet files and using the support in bitcoinj for
running them in parallel), but they decided to remove this feature in
MultiBit HD because it caused support headaches. People would stash money
in one wallet or the other, close the wallet and then forget and think they
had lost it, etc. It may be that TREZOR type subwallets don't suffer this
confusion because they can't be moved around or "closed" in the same way a
file can be, but still, this is a data point against multiple simultaneous
wallets. At least for products targeting entry level consumers.
Whilst I can well believe there are TREZOR users who are asking for this
feature today, currently the costs feel a bit higher than the benefits.
It would be rather nice to be able to type in a mnemonic code that myTREZOR
was initialised with and duplicate that wallet into a bitcoinj based wallet
app. But if I have to implement subwallets and expose this in the API, and
if all wallet authors that want to be able to share a wallet with myTREZOR
have to expose subwallets in their GUIs too, even though the concept may
prove confusing and hard to explain, then it might be more tempting to just
tell users that want to switch wallet apps to send the money via the block
chain instead.
On Thu, Apr 24, 2014 at 9:10 AM, Pieter Wuille <pieter.wuille@gmail.com>wrote:
> On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin <thomasv1@gmx.de> wrote:
> >> Why do clients need to use the features in BIP 64? If Electrum doesn't
> want to
> >> use accounts, [...]
> >
> > To clarify:
> > Electrum plans to have bip32 accounts; Multibit will not, afaik.
>
> To clarify:
> BIP64 has a much stricter definition for accounts than BIP32.
>
> In BIP32, it is not well specified what accounts are used for. They
> can be used for "subwallets", "receive accounts" (as in bitcoind's
> account feature), "recurring payments", part of a chain used as
> multisig addresses, ... determined individually for each index.
>
> In BIP64, they are strictly used for subwallets, and can't be used by
> anything else.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> 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
>
--001a113356c624e6ee04f7c55ea6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Right. So part of this is my fault, I'm afraid, becaus=
e I do not intend to implement any kind of subwallet/account support in bit=
coinj. My reasons are:<div><ol><li>The bitcoinj API already lets you create=
and use multiple wallets. What's more, because of the desire to do key=
rotation (think rotating a previously unencrypted wallet to an encrypted o=
ne that is stored on SSD's that cannot reliably erase data), a bitcoinj=
wallet can actually contain multiple BIP32 seeds and hierarchies at once, =
although only the last one will be used for vending addresses. So adding su=
bwallet support onto this makes it even more complicated.<br>
<br></li><li>If there was a much better user experience to be enabled by th=
is, it may be worth it, but I believe many people will find subwallets rath=
er confusing. They don't match the analogy of bank accounts in several =
ways. For instance, transferring money across them leaks private data and c=
osts miners fees, neither of which are true with banks.=C2=A0<br>
<br>Also it differs in a more important way. People have different bank acc=
ounts because those accounts implement different policies. Current accounts=
may pay a lower interest rate than savings accounts, but have different fe=
atures, and accounts can be used as security boundaries i.e. no card withdr=
awals from savings. But "subwallets" are not like this. The only =
justification for their existence is to avoid outputs being merged together=
to make payments - a subtle technical detail of the protocol that users ar=
e ill equipped to understand. If someone asked me "why should I create=
a second account" I would be unable to give them a satisfying answer =
without first teaching them about how the Bitcoin protocol works and the pr=
ivacy implications of that, which is practically a lecture sized topic.<br>
<br></li><li>MultiBit did support multiple wallets for a long time (just by=
creating multiple wallet files and using the support in bitcoinj for runni=
ng them in parallel), but they decided to remove this feature in MultiBit H=
D because it caused support headaches. People would stash money in one wall=
et or the other, close the wallet and then forget and think they had lost i=
t, etc. It may be that TREZOR type subwallets don't suffer this confusi=
on because they can't be moved around or "closed" in the same=
way a file can be, but still, this is a data point against multiple simult=
aneous wallets. At least for products targeting entry level consumers.</li>
</ol><div>Whilst I can well believe there are TREZOR users who are asking f=
or this feature today, currently the costs feel a bit higher than the benef=
its.</div></div><div><br></div><div>It would be rather nice to be able to t=
ype in a mnemonic code that myTREZOR was initialised with and duplicate tha=
t wallet into a bitcoinj based wallet app. But if I have to implement subwa=
llets and expose this in the API, and if all wallet authors that want to be=
able to share a wallet with myTREZOR have to expose subwallets in their GU=
Is too, even though the concept may prove confusing and hard to explain, th=
en it might be more tempting to just tell users that want to switch wallet =
apps to send the money via the block chain instead.</div>
<div><br></div><div><br></div></div><div class=3D"gmail_extra"><br><br><div=
class=3D"gmail_quote">On Thu, Apr 24, 2014 at 9:10 AM, Pieter Wuille <span=
dir=3D"ltr"><<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blan=
k">pieter.wuille@gmail.com</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"">On Thu, Apr 24, 2014 at 8:54=
AM, Thomas Voegtlin <<a href=3D"mailto:thomasv1@gmx.de">thomasv1@gmx.de=
</a>> wrote:<br>
>> Why do clients need to use the features in BIP 64? If Electrum doe=
sn't want to<br>
>> use accounts, [...]<br>
><br>
> To clarify:<br>
> Electrum plans to have bip32 accounts; Multibit will not, afaik.<br>
<br>
</div>To clarify:<br>
BIP64 has a much stricter definition for accounts than BIP32.<br>
<br>
In BIP32, it is not well specified what accounts are used for. They<br>
can be used for "subwallets", "receive accounts" (as in=
bitcoind's<br>
account feature), "recurring payments", part of a chain used as<b=
r>
multisig addresses, ... determined individually for each index.<br>
<br>
In BIP64, they are strictly used for subwallets, and can't be used by<b=
r>
anything else.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Pieter<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><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>
--001a113356c624e6ee04f7c55ea6--
|
