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
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1UrrfZ-00059A-TI
for bitcoin-development@lists.sourceforge.net;
Wed, 26 Jun 2013 15:30:06 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.176 as permitted sender)
client-ip=209.85.223.176; envelope-from=etotheipi@gmail.com;
helo=mail-ie0-f176.google.com;
Received: from mail-ie0-f176.google.com ([209.85.223.176])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UrrfW-0000ci-HG
for bitcoin-development@lists.sourceforge.net;
Wed, 26 Jun 2013 15:30:05 +0000
Received: by mail-ie0-f176.google.com with SMTP id ar20so30108049iec.7
for <bitcoin-development@lists.sourceforge.net>;
Wed, 26 Jun 2013 08:29:57 -0700 (PDT)
X-Received: by 10.50.126.99 with SMTP id mx3mr2097142igb.48.1372260597154;
Wed, 26 Jun 2013 08:29:57 -0700 (PDT)
Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net.
[76.111.96.126])
by mx.google.com with ESMTPSA id r20sm8502451ign.8.2013.06.26.08.29.55
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Wed, 26 Jun 2013 08:29:56 -0700 (PDT)
Message-ID: <51CB08EE.1050403@gmail.com>
Date: Wed, 26 Jun 2013 11:29:50 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <5AC3FA1D9B1F4FA0A2FE9A67333642B5@LAPTOPAIR>
<51C21035.9080407@gmail.com>
<53E406CF0D93498DAECAAE061555B7C9@LAPTOPAIR>
<51C234FA.5030909@gmail.com>
<9600E3D1DDC24D1391C1E4433F71684D@LAPTOPAIR>
<CANEZrP3ZcQEPOPrO_O2-tdLZUSezj1nbhtVFt1e77KEwzhfZ-A@mail.gmail.com>
In-Reply-To: <CANEZrP3ZcQEPOPrO_O2-tdLZUSezj1nbhtVFt1e77KEwzhfZ-A@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative;
boundary="------------040906020302010007090602"
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
(etotheipi[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: 1UrrfW-0000ci-HG
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: Wed, 26 Jun 2013 15:30:06 -0000
This is a multi-part message in MIME format.
--------------040906020302010007090602
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Although I'd still prefer my original request, I get much of what I want
from your guys' recommendation. It complicates the wallet design,
because it requires tracking and associating a matrix of addresses for
each wallet, instead of a single linear list. But if this is what it's
going to take then I will go along.
Right now BIP 32 defines, m/i'/j/k, where j=0 is the "external" chain
used for distributing addresses, and j=1 is the "internal" chain for
sending change. The CONOPs (concept of operations) for the extended
wallet would be like Jeremy described:
- Chains with j>=2 would be independent address chains carved out for
individuals relationships
- Add wallet code to individually associate each j-value with a
particular identity
- Update the wallet code to pool all the addresses in all j-chains when
calculating the balance of the wallet and/or creating transactions
- When choosing to generically "Receive Bitcoins", will pick the next
address from the j=0 chain
- Will have to add extra function to "Receive Bitcoins" button to allow
creation of new contacts/identities.
- Change will always go to the next address in j=1, no matter which
chains are used to provide inputs.
- Add code to figure out lookaheads for each alternate chain. Not just
each chain, but looking ahead a couple chains, too. Luckily, the
lookahead doesn't have to be very big for chains j>=1
- Add an interface to display and choose the different chains in your
wallet, and export the pubkey&chaincode in some soon-to-be-standardized
format.
- Add code and interface to receive and track alternate j-chains from
other clients/users, and maintain those. Should we try associating
incoming and outgoing chains? What happens if they do it wrong? Meh...
Just as one final swipe at this idea, you can see that I gotta do quite
a bit of work to support the multi-chain idea, and adds a little extra
burden on the user to maintain the organization of the wallet. This
would all be totally unnecessary with a simple alternate encoding.
Granted, I think the multi-chain idea is good, and one that I will
probably implement anyway, but it seems like overkill in terms of
developer complexity, and interface complexity to achieve something much
simpler. Developers of much simpler/lightweight clients would probably
find this prohibitive.
On another note: I thought we weren't encouraging automatic payments
without requesting from the other party...? It makes me uneasy, but it
sounds like group thought has converged on that being acceptable. I
bring it up, because there are situations where it makes sense, but it
sounds unsafe for general users. Alice will give Bob his own chain for
sending Alice money, then a year later Bob will send money automatically
to Alice not realizing that the wallet was lost, retired or
compromised. It's not that Bob can't ask for a new address, it's that
if the interface says "Send Money to Alice", that looks legit enough
that Bob may not feel it necessary to check with Alice first. That's
more of an interface issue though. We can add a warning to "check with
the recipient that they still have access to wallet 3cQ398x", etc. But
I just know someone is going to lose money anyway...
-Alan
On 06/20/2013 03:32 AM, Mike Hearn wrote:
> 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
> <mailto: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 code
> from [m/i'/0] so that you can receive payments at [m/i'/0/k], for
> a unique
> 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=2
> don't make
> sense for handing out receive chains to lots of people anyway, and
> certainly
> BIP32 doesn't *require* 0 <= j <= 1. So I think incrementing 'j'
> is the way
> to go here...
>
> The "default" layout of BIP32 does NOT mean that implementations
> should not
> 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 call
> it the 'Addend' not the 'Multiplier' :-)
>
> > Do these extra wallet chains behave as different wallets, or
> sub-wallets?
>
> 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
> "magically" 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
> *result*
> of CKD'((Kpar, cpar), k), and instead I proposed passing Kpar and
> cpar, and
> 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
> services,
> corresponding to user's identity rooted in [m/i']. Each service
> gets their
> own 'j'. ParentPubKey + Addend gives you the PubKey of [m/i'/j].
> With the
> 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
> <mailto:Bitcoin-development@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> 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
--------------040906020302010007090602
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Although I'd still prefer my original request, I get much of what I
want from your guys' recommendation. It complicates the wallet
design, because it requires tracking and associating a matrix of
addresses for each wallet, instead of a single linear list. But if
this is what it's going to take then I will go along. <br>
<br>
Right now BIP 32 defines, m/i'/j/k, where j=0 is the "external"
chain used for distributing addresses, and j=1 is the "internal"
chain for sending change. The CONOPs (concept of operations) for
the extended wallet would be like Jeremy described:<br>
<br>
- Chains with j>=2 would be independent address chains carved out
for individuals relationships<br>
- Add wallet code to individually associate each j-value with a
particular identity<br>
- Update the wallet code to pool all the addresses in all j-chains
when calculating the balance of the wallet and/or creating
transactions<br>
- When choosing to generically "Receive Bitcoins", will pick the
next address from the j=0 chain<br>
- Will have to add extra function to "Receive Bitcoins" button to
allow creation of new contacts/identities.<br>
- Change will always go to the next address in j=1, no matter which
chains are used to provide inputs.<br>
- Add code to figure out lookaheads for each alternate chain. Not
just each chain, but looking ahead a couple chains, too. Luckily,
the lookahead doesn't have to be very big for chains j>=1 <br>
- Add an interface to display and choose the different chains in
your wallet, and export the pubkey&chaincode in some
soon-to-be-standardized format. <br>
- Add code and interface to receive and track alternate j-chains
from other clients/users, and maintain those. Should we try
associating incoming and outgoing chains? What happens if they do
it wrong? Meh...<br>
<br>
Just as one final swipe at this idea, you can see that I gotta do
quite a bit of work to support the multi-chain idea, and adds a
little extra burden on the user to maintain the organization of the
wallet. This would all be totally unnecessary with a simple
alternate encoding. Granted, I think the multi-chain idea is good,
and one that I will probably implement anyway, but it seems like
overkill in terms of developer complexity, and interface complexity
to achieve something much simpler. Developers of much
simpler/lightweight clients would probably find this prohibitive.<br>
<br>
On another note: I thought we weren't encouraging automatic
payments without requesting from the other party...? It makes me
uneasy, but it sounds like group thought has converged on that being
acceptable. I bring it up, because there are situations where it
makes sense, but it sounds unsafe for general users. Alice will
give Bob his own chain for sending Alice money, then a year later
Bob will send money automatically to Alice not realizing that the
wallet was lost, retired or compromised. It's not that Bob can't
ask for a new address, it's that if the interface says "Send Money
to Alice", that looks legit enough that Bob may not feel it
necessary to check with Alice first. That's more of an interface
issue though. We can add a warning to "check with the recipient
that they still have access to wallet 3cQ398x", etc. But I just
know someone is going to lose money anyway...<br>
<br>
-Alan<br>
<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 06/20/2013 03:32 AM, Mike Hearn
wrote:<br>
</div>
<blockquote
cite="mid:CANEZrP3ZcQEPOPrO_O2-tdLZUSezj1nbhtVFt1e77KEwzhfZ-A@mail.gmail.com"
type="cite">
<div dir="ltr">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.</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Jun 20, 2013 at 5:54 AM, Jeremy
Spilman <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:jeremy@taplink.co" target="_blank">jeremy@taplink.co</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> BIP 32 already specifies how to use the
first three tree levels: M/i/j/k,<br>
> i~wallet, j~Internal/External, k~address. The first
level is actually<br>
> type-1 derived, and thus we cannot create an
arbitrary number of them<br>
> without pre-computing them from the offline wallet.
So 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 chain 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, as<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=2 don't make<br>
sense for handing out receive chains to lots of people
anyway, and certainly<br>
BIP32 doesn't *require* 0 <= j <= 1. So I think
incrementing '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 and<br>
obviously self-limiting. It might be helpful to add to the
'Compatibility'<br>
section some minimum expectations about how a wallet should
be 'probed' 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 BIP32<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="im"><br>
> Do these extra wallet chains behave as different
wallets, or sub-wallets?<br>
<br>
</div>
They could, but they certainly don't need to! A
single-wallet<br>
implementation treats this merely as an address-generation
algorithm, and<br>
does not expose any hierarchy to the user interface. The
user just<br>
“magically” gets the ability to send multiple payments to
their contacts<br>
without immediately sacrificing their privacy<br>
(<a moz-do-not-send="true"
href="http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/"
target="_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 is<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 only<br>
difference is that you are passing the Kpar for [m/i'/0/k]
and the *result*<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="im"><br>
> For instance, maybe there's a benefit to using the
same parent pubkey<br>
</div>
> across multiple services, as a form of identity. If I
don't want that, I<br>
<div class="im">> use your method. If I do want that, I
use my method.<br>
<br>
</div>
I think it's a interesting idea using static public keys as
a means 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 get<br>
all the benefits, by making the data structure {
ParentPubKey, Addend,<br>
ChainCode }:<br>
<br>
ParentPubKey: Public key of m/i' -- 33 bytes<br>
Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes<br>
ChainCode: I[R] from CDK'(m/i', j) -- 32 bytes<br>
<br>
All that remains secret is the ChainCode from [m/i'] -- and
of course the<br>
private keys. The ParentPubKey is a common value across
multiple services,<br>
corresponding to user's identity rooted in [m/i']. Each
service gets their<br>
own 'j'. ParentPubKey + Addend gives you the PubKey of
[m/i'/j]. With the<br>
ChainCode, the receiver then can generate [m/i'/j/k] for
monotonically<br>
increasing 'k'. Again, from the user perspective all
transactions under<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 initial<br>
exchange, and it need not complicate the wallet.<br>
<div class="HOEnZb">
<div class="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 moz-do-not-send="true"
href="http://p.sf.net/sfu/windows-dev2dev"
target="_blank">http://p.sf.net/sfu/windows-dev2dev</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a moz-do-not-send="true"
href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development"
target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/windows-dev2dev">http://p.sf.net/sfu/windows-dev2dev</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------040906020302010007090602--
|