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
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1UpZM6-0000kc-1h
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Jun 2013 07:32:30 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.180 as permitted sender)
client-ip=209.85.214.180; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f180.google.com;
Received: from mail-ob0-f180.google.com ([209.85.214.180])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UpZM4-0000e6-1R
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Jun 2013 07:32:30 +0000
Received: by mail-ob0-f180.google.com with SMTP id eh20so6737277obb.39
for <bitcoin-development@lists.sourceforge.net>;
Thu, 20 Jun 2013 00:32:22 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.47.130 with SMTP id d2mr3991208oen.67.1371713542627; Thu,
20 Jun 2013 00:32:22 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.23.36 with HTTP; Thu, 20 Jun 2013 00:32:22 -0700 (PDT)
In-Reply-To: <9600E3D1DDC24D1391C1E4433F71684D@LAPTOPAIR>
References: <5AC3FA1D9B1F4FA0A2FE9A67333642B5@LAPTOPAIR>
<51C21035.9080407@gmail.com>
<53E406CF0D93498DAECAAE061555B7C9@LAPTOPAIR>
<51C234FA.5030909@gmail.com>
<9600E3D1DDC24D1391C1E4433F71684D@LAPTOPAIR>
Date: Thu, 20 Jun 2013 09:32:22 +0200
X-Google-Sender-Auth: qzkGnWFWup3q3HyBFQrgpEaJjCs
Message-ID: <CANEZrP3ZcQEPOPrO_O2-tdLZUSezj1nbhtVFt1e77KEwzhfZ-A@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeremy Spilman <jeremy@taplink.co>
Content-Type: multipart/alternative; boundary=001a11c30992712a9804df90f274
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: 1UpZM4-0000e6-1R
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Optional "wallet-linkable" address format
- Payment Protocol
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, 20 Jun 2013 07:32:30 -0000
--001a11c30992712a9804df90f274
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Agree with Jeremy and once the payment protocol work is further along I'd
like to see us define an extension that lets you send payment requests
containing public keys+chain codes, so further payments can be made
push-style with no recipient interaction (e.g. for repeated billing). How
apps choose to arrange their chains internally seems like an area for
experimentation. I definitely want to implement HD wallets in bitcoinj to
allow this and if that means not using the same tree structure as in the
BIP then so be it.
On Thu, Jun 20, 2013 at 5:54 AM, Jeremy Spilman <jeremy@taplink.co> wrote:
> > BIP 32 already specifies how to use the first three tree levels:
> M/i/j/k,
> > i~wallet, j~Internal/External, k~address. The first level is actually
> > type-1 derived, and thus we cannot create an arbitrary number of them
> > without pre-computing them from the offline wallet. So it's not "free"
> to
> > create new wallets unless we redefine how the levels work.
>
> Initially I was thinking that you would share the public key and chain co=
de
> from [m/i'/0] so that you can receive payments at [m/i'/0/k], for a uniqu=
e
> value of 'i' for each receive chain.
>
> For the case of generating new receive chains from a *watch-only* wallet,
> as
> you say, the options are to either keep a cache of PubKey/ChainCode for
> unused [m/i'] or simply increment 'j' past 1 for an existing [m/i'/j] --
> the
> concept of 'internal/'external' and change addresses at Depth=3D2 don't m=
ake
> sense for handing out receive chains to lots of people anyway, and
> certainly
> BIP32 doesn't *require* 0 <=3D j <=3D 1. So I think incrementing 'j' is =
the
> way
> to go here...
>
> The "default" layout of BIP32 does NOT mean that implementations should n=
ot
> check for transactions with j > 1. That would be a useless constraint and
> obviously self-limiting. It might be helpful to add to the 'Compatibility=
'
> section some minimum expectations about how a wallet should be 'probed'
> when
> imported. If you don't feel completely free to monotonically increment 'j=
'
> to your hearts content to achieve major usability benefits, then I say
> BIP32
> could use some clarifying.
>
> BTW - the spec calls for addition not multiplication now, so we should ca=
ll
> it the 'Addend' not the 'Multiplier' :-)
>
> > Do these extra wallet chains behave as different wallets, or sub-wallet=
s?
>
> They could, but they certainly don't need to! A single-wallet
> implementation treats this merely as an address-generation algorithm, and
> does not expose any hierarchy to the user interface. The user just
> =E2=80=9Cmagically=E2=80=9D gets the ability to send multiple payments to=
their contacts
> without immediately sacrificing their privacy
> (http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/). Everything
> goes into the same ledger, balance, coin pool, etc. Most of the code base
> is
> unaware BIP32 is even in use.
>
> While it is *possible* to support separate ledgers, balances, etc. it is
> certainly not required, and you get all the benefits either way.
>
> I think, since your proposal generates and receives payments into
> BIP32-style addresses, we both need similar underlying wallet code. The
> only
> difference is that you are passing the Kpar for [m/i'/0/k] and the *resul=
t*
> of CKD'((Kpar, cpar), k), and instead I proposed passing Kpar and cpar, a=
nd
> leaving 'k' out of it, letting the receive choose 'k'.
>
> > For instance, maybe there's a benefit to using the same parent pubkey
> > across multiple services, as a form of identity. If I don't want that=
,
> I
> > use your method. If I do want that, I use my method.
>
> I think it's a interesting idea using static public keys as a means for
> persistent identity and hence security from MitM. If you want a shared
> public key across multiple services we could just combine both ideas and
> get
> all the benefits, by making the data structure { ParentPubKey, Addend,
> ChainCode }:
>
> ParentPubKey: Public key of m/i' -- 33 bytes
> Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes
> ChainCode: I[R] from CDK'(m/i', j) -- 32 bytes
>
> All that remains secret is the ChainCode from [m/i'] -- and of course the
> private keys. The ParentPubKey is a common value across multiple service=
s,
> corresponding to user's identity rooted in [m/i']. Each service gets the=
ir
> own 'j'. ParentPubKey + Addend gives you the PubKey of [m/i'/j]. With t=
he
> ChainCode, the receiver then can generate [m/i'/j/k] for monotonically
> increasing 'k'. Again, from the user perspective all transactions under
> [m/i'] can be presented in a single ledger, or not.
>
> Anyway, fundamentally my feedback is if you are designing for persistent
> long-term relationships, you could build in a mechanism for generating
> address chains so you don't need any further communication after the
> initial
> exchange, and it need not complicate the wallet.
>
> Thanks,
> --Jeremy
>
>
>
>
> -------------------------------------------------------------------------=
-----
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--001a11c30992712a9804df90f274
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Agree with Jeremy and once the payment protocol work is fu=
rther along I'd like to see us define an extension that lets you send p=
ayment requests containing public keys+chain codes, so further payments can=
be made push-style with no recipient interaction (e.g. for repeated billin=
g). How apps choose to arrange their chains internally seems like an area f=
or experimentation. I definitely want to implement HD wallets in bitcoinj t=
o allow this and if that means not using the same tree structure as in the =
BIP then so be it.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Jun 2=
0, 2013 at 5:54 AM, Jeremy Spilman <span dir=3D"ltr"><<a href=3D"mailto:=
jeremy@taplink.co" target=3D"_blank">jeremy@taplink.co</a>></span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div class=3D"im">> BIP 32 already specifies how to use the first three =
tree levels: =C2=A0M/i/j/k,<br>
> i~wallet, j~Internal/External, k~address. =C2=A0The first level is act=
ually<br>
> type-1 derived, and thus we cannot create an arbitrary number of them<=
br>
> without pre-computing them from the offline wallet. =C2=A0So it's =
not "free" to<br>
> create new wallets unless we redefine how the levels work.<br>
<br>
</div>Initially I was thinking that you would share the public key and chai=
n code<br>
from [m/i'/0] so that you can receive payments at [m/i'/0/k], for a=
unique<br>
value of 'i' for each receive chain.<br>
<br>
For the case of generating new receive chains from a *watch-only* wallet, a=
s<br>
you say, the options are to either keep a cache of PubKey/ChainCode for<br>
unused [m/i'] or simply increment 'j' past 1 for an existing [m=
/i'/j] -- the<br>
concept of 'internal/'external' and change addresses at Depth=
=3D2 don't make<br>
sense for handing out receive chains to lots of people anyway, and certainl=
y<br>
BIP32 doesn't *require* 0 <=3D j <=3D 1. =C2=A0So I think increme=
nting 'j' is the way<br>
to go here...<br>
<br>
The "default" layout of BIP32 does NOT mean that implementations =
should not<br>
check for transactions with j > 1. That would be a useless constraint an=
d<br>
obviously self-limiting. It might be helpful to add to the 'Compatibili=
ty'<br>
section some minimum expectations about how a wallet should be 'probed&=
#39; when<br>
imported. If you don't feel completely free to monotonically increment =
'j'<br>
to your hearts content to achieve major usability benefits, then I say BIP3=
2<br>
could use some clarifying.<br>
<br>
BTW - the spec calls for addition not multiplication now, so we should call=
<br>
it the 'Addend' not the 'Multiplier' :-)<br>
<div class=3D"im"><br>
> Do these extra wallet chains behave as different wallets, or sub-walle=
ts?<br>
<br>
</div>They could, but they certainly don't need to! =C2=A0A single-wall=
et<br>
implementation treats this merely as an address-generation algorithm, and<b=
r>
does not expose any hierarchy to the user interface. =C2=A0The user just<br=
>
=E2=80=9Cmagically=E2=80=9D gets the ability to send multiple payments to t=
heir contacts<br>
without immediately sacrificing their privacy<br>
(<a href=3D"http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/" ta=
rget=3D"_blank">http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/=
</a>). Everything<br>
goes into the same ledger, balance, coin pool, etc. Most of the code base i=
s<br>
unaware BIP32 is even in use.<br>
<br>
While it is *possible* to support separate ledgers, balances, etc. it is<br=
>
certainly not required, and you get all the benefits either way.<br>
<br>
I think, since your proposal generates and receives payments into<br>
BIP32-style addresses, we both need similar underlying wallet code. The onl=
y<br>
difference is that you are passing the Kpar for [m/i'/0/k] and the *res=
ult*<br>
of CKD'((Kpar, cpar), k), and instead I proposed passing Kpar and cpar,=
and<br>
leaving 'k' out of it, letting the receive choose 'k'.<br>
<div class=3D"im"><br>
> For instance, maybe there's a benefit to using the same parent pub=
key<br>
</div>> across multiple services, as a form of identity. =C2=A0 If I don=
't want that, I<br>
<div class=3D"im">> use your method. =C2=A0If I do want that, I use my m=
ethod.<br>
<br>
</div>I think it's a interesting idea using static public keys as a mea=
ns for<br>
persistent identity and hence security from MitM. If you want a shared<br>
public key across multiple services we could just combine both ideas and ge=
t<br>
all the benefits, by making the data structure { ParentPubKey, Addend,<br>
ChainCode }:<br>
<br>
=C2=A0 =C2=A0ParentPubKey: Public key of m/i' -- 33 bytes<br>
=C2=A0 =C2=A0Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes<br>
=C2=A0 =C2=A0ChainCode: I[R] from CDK'(m/i', j) -- 32 bytes<br>
<br>
All that remains secret is the ChainCode from [m/i'] -- and of course t=
he<br>
private keys. =C2=A0The ParentPubKey is a common value across multiple serv=
ices,<br>
corresponding to user's identity rooted in [m/i']. =C2=A0Each servi=
ce gets their<br>
own 'j'. =C2=A0ParentPubKey + Addend gives you the PubKey of [m/i&#=
39;/j]. =C2=A0With the<br>
ChainCode, the receiver then can generate [m/i'/j/k] for monotonically<=
br>
increasing 'k'. Again, from the user perspective all transactions u=
nder<br>
[m/i'] can be presented in a single ledger, or not.<br>
<br>
Anyway, fundamentally my feedback is if you are designing for persistent<br=
>
long-term relationships, you could build in a mechanism for generating<br>
address chains so you don't need any further communication after the in=
itial<br>
exchange, and it need not complicate the wallet.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
Thanks,<br>
--Jeremy<br>
<br>
<br>
<br>
---------------------------------------------------------------------------=
---<br>
This SF.net email is sponsored by Windows:<br>
<br>
Build for Windows Store.<br>
<br>
<a href=3D"http://p.sf.net/sfu/windows-dev2dev" target=3D"_blank">http://p.=
sf.net/sfu/windows-dev2dev</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>
--001a11c30992712a9804df90f274--
|