summaryrefslogtreecommitdiff
path: root/18/364423c10c4f8e92b006c304fa378465f6f04e
blob: 825c939e51b0d0c3b8d5740203b608133195380c (plain)
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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <paul@airbitz.co>) id 1YJXbC-0000Kd-Qk
	for bitcoin-development@lists.sourceforge.net;
	Fri, 06 Feb 2015 01:20:46 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of airbitz.co
	designates 209.85.220.42 as permitted sender)
	client-ip=209.85.220.42; envelope-from=paul@airbitz.co;
	helo=mail-pa0-f42.google.com; 
Received: from mail-pa0-f42.google.com ([209.85.220.42])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YJXb7-0004wg-IT
	for bitcoin-development@lists.sourceforge.net;
	Fri, 06 Feb 2015 01:20:46 +0000
Received: by mail-pa0-f42.google.com with SMTP id bj1so13724073pad.1
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 05 Feb 2015 17:20:32 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:content-type:mime-version:subject:from
	:in-reply-to:date:cc:content-transfer-encoding:message-id:references
	:to; bh=CaprB1rT/L592DqtUy/him+D9NgZn2Ej62VpgT2snJk=;
	b=BPjmLsKRpWI9+ZZ+93HmIipoJ961ZRarsmUUS+Jdbapp0DguXvADF3+OyRo2UB6xUK
	+lw9cQQHB0xuoPw5vyhjSoQAM5RPBLOcu/+HA55ytgaaVGxiuFzi+7zeGuJFWIqtIdze
	7Cr3H0uJqmZYUIqm3Gma4RQB1ORmH/6LeYQkCzMQzH+izp35DvUnb5j84Kt2j8CPvK4H
	dvO/MU4VWgN8pGDAfZM2AAnE6O4c06C6uqaFYLERkUi34Jv+7GbVXquuSPigYEeK8t7d
	avsQDOZjwAzxYZqwleMYx3/FTDawCjqKpEz6ODCiBAxZKv64B4yJaUMb20l0McdxzQ3f
	E/mQ==
X-Gm-Message-State: ALoCoQlkSzBdWdqs+/aVoOpIFpk86A8ISR0MTRWciJQSLqulzwEAI+uR7/sqNHaazxFcYvRhJiwN
X-Received: by 10.70.48.33 with SMTP id i1mr1404136pdn.153.1423184322575;
	Thu, 05 Feb 2015 16:58:42 -0800 (PST)
Received: from [10.204.163.123] (mobile-166-171-251-007.mycingular.net.
	[166.171.251.7])
	by mx.google.com with ESMTPSA id bc1sm6267075pad.12.2015.02.05.16.58.40
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 05 Feb 2015 16:58:41 -0800 (PST)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-32EFC4CE-12D4-4DF8-86EA-A859F42DA7F0
Mime-Version: 1.0 (1.0)
From: Paul Puey <paul@airbitz.co>
X-Mailer: iPhone Mail (12B411)
In-Reply-To: <20150205233421.GP39876@giles.gnomon.org.uk>
Date: Thu, 5 Feb 2015 16:58:39 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <5D9B0989-0AE1-40FB-8B73-69D352BDB29A@airbitz.co>
References: <CABdy8DKS4arkkCLGC=66SUJm5Ugib1EWP7B6MkQRX1k-yd3WBw@mail.gmail.com>
	<CANEZrP3v=ySS4gragaWuBMWi_swocRRRq_kw2edo6+9kifgrFQ@mail.gmail.com>
	<54D3D636.1030308@voskuil.org>
	<CANEZrP3ekWQWeV=Yw_E=n0grORBLHaXLUh3w0EFQdz=HsjWvZw@mail.gmail.com>
	<279489A5-1E46-48A2-8F58-1A25821D4D96@gmail.com>
	<CANEZrP3VAWajxE=mNxb6sLSQbhaQHD=2TgRKvYrEax2PAzCi2A@mail.gmail.com>
	<6AEDF3C4-DEE0-4E31-83D0-4FD92B125452@voskuil.org>
	<CABdy8DLRGyy5dvmVb_B3vao7Qwz-zdAC3-+2nJkg9rSsU6FLbw@mail.gmail.com>
	<C28CD881-DAB8-4EDB-B239-7D45A825EAF0@voskuil.org>
	<CABjHNoTmj=wfjRwApZCJJTDhhwePh=VtXkJN0e3t1uQqmeMu6Q@mail.gmail.com>
	<20150205233421.GP39876@giles.gnomon.org.uk>
To: Roy Badami <roy@gnomon.org.uk>
X-Spam-Score: -0.3 (/)
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 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.3 HTML_FONT_FACE_BAD     BODY: HTML font face is not a word
	0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
	-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
	0.0 T_REMOTE_IMAGE         Message contains an external image
X-Headers-End: 1YJXb7-0004wg-IT
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE)
	transfer of Payment URI
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: Fri, 06 Feb 2015 01:20:46 -0000


--Apple-Mail-32EFC4CE-12D4-4DF8-86EA-A859F42DA7F0
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Although consumer to merchant is a use case for BLE I would argue that NFC h=
as a higher chance of providing a better user experience in most cases since=
, at least on Android, a user can tap their phone without even having a wall=
et running. The URI handler will launch the wallet for them. However a dedic=
ated, user facing, screen can give certainty that the user is connecting to t=
he correct recipient.=20

1. Because it can show an address prefix=20
2. It can display the users nickname/handle upon connecting which is only se=
nt to the merchant upon a point to point connection. Not a broadcast.=20

The Airbitz wallet already does this on the recipient side. A popup shows th=
e most recent person connecting to the recipient.=20


  =20
Paul Puey CEO / Co-Founder, Airbitz Inc
619.850.8624 | http://airbitz.co | San Diego
    =20



On Feb 5, 2015, at 3:34 PM, Roy Badami <roy@gnomon.org.uk> wrote:

For peer-to-peer payments, how common do we think that the payment is
of an ad hoc nature rather than to a known contact?

If I want to pay my friends/colleagues/etc over a restaurant table
there's no reason why I couldn't already have their public keys in my
contact list - then it would be pretty straightforward to have a
watertight mechanism where I would know who I was paying.  You could
probably even relatively securely bootstrap a key exchange over SMS,
relying only on the contacts already having each other in their
phonebooks.

As for comsumer-to-merchant transactions where the merchant is a
bricks and mortar merchant, IMHO it absolutely has to be "pay that
terminal over there".  It's the trust model we all currently use -
whether paying cash or card - and it's the only trust model that works
IMHO (and customers and businesses alike are well aware of the risks
of a fraudster standing behind the counter pretending to be an
employee accepting payment - and by and large are pretty good at
mitigating it).  OTOH as we've discussed here before there are many
use cases where the custoemr doesn't actually know or care about the
name of the shop or bar they walked into but is pretty damn sure that
they need to make payment to the person over there behind the counter.

Granted, there are cases taht dont' fall into either of the above -
but they're the cases that are (a) harder to figure out how to
authenticate and consequently (b) the use cases that are going to be
most subject to attempted fraud.

roy

> On Thu, Feb 05, 2015 at 03:02:56PM -0800, William Swanson wrote:
>> On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil <eric@voskuil.org> wrote:
>> A MITM can receive the initial broadcast and then spoof it by jamming the=

>> original. You then only see one.
>=20
> You are right, of course. There is no way to make Bluetooth 100%
> secure, since it is an over-the-air technology. You could try securing
> it using a CA or other identity server, but now you've excluded ad-hoc
> person-to-person payments. Plus, you need an active internet
> connection to reach the CA.
>=20
> You can try using proximity as a substitute for identity, like
> requiring NFC to kick-start the connection, but at that point you
> might as well use QR codes.
>=20
> This BIP is not trying to provide absolute bullet-proof security,
> since that's impossible given the physical limitations of the
> Bluetooth technology. Instead, it's trying to provide the
> best-possible security given those constraints. In exchange for this,
> we get greatly enhanced usability in common scenarios.
>=20
> There are plenty of usable, real-world technologies with big security
> holes. Anybody with lock-picking experience will tell you this, but
> nobody is welding their front door shut. The ability to go in and out
> is worth the security risk.
>=20
> Bluetooth payments add a whole new dimension to real-world Bitcoin
> usability. Do we shut that down because it can't be made perfect, or
> do we do the best we can and move forward?
>=20
> -William
>=20
> --------------------------------------------------------------------------=
----
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is yo=
ur
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a=

> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20

--Apple-Mail-32EFC4CE-12D4-4DF8-86EA-A859F42DA7F0
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>Although consumer to merchant is a use=
 case for BLE I would argue that NFC has a higher chance of providing a bett=
er user experience in most cases since, at least on Android, a user can tap t=
heir phone without even having a wallet running. The URI handler will launch=
 the wallet for them. However a dedicated, user facing, screen can give cert=
ainty that the user is connecting to the correct recipient.&nbsp;</div><div>=
<br></div><div>1. Because it can show an address prefix&nbsp;</div><div>2. I=
t can display the users nickname/handle upon connecting which is only sent t=
o the merchant upon a point to point connection. Not a broadcast.&nbsp;</div=
><div><br></div><div>The Airbitz wallet already does this on the recipient s=
ide. A popup shows the most recent person connecting to the recipient.&nbsp;=
</div><div><br><span style=3D"background-color: rgba(255, 255, 255, 0);"><br=
></span><table border=3D"0" style=3D"-webkit-text-size-adjust: auto; font-si=
ze: medium; font-family: Helvetica, Arial, sans-serif;"><tbody><tr valign=3D=
"top"><td style=3D"width: auto; vertical-align: top;"><font face=3D".Helveti=
caNeueInterface-M3"><span style=3D"font-size: 17px; -webkit-text-size-adjust=
: none; background-color: rgba(255, 255, 255, 0);"><img src=3D"https://s3.am=
azonaws.com/webapp.wisestamp.com/v7Zg7GfIQ9mF5xlHZrZA_airbitzlogo.png" alt=3D=
"logo" style=3D"border: none; border-top-left-radius: 4px; border-top-right-=
radius: 4px; border-bottom-right-radius: 4px; border-bottom-left-radius: 4px=
;">&nbsp;&nbsp;&nbsp;<br></span></font></td><td><font face=3D".HelveticaNeue=
Interface-M3"><span style=3D"font-size: 17px; -webkit-text-size-adjust: none=
; background-color: rgba(255, 255, 255, 0);"><b>Paul Puey</b>&nbsp;CEO / Co-=
Founder, Airbitz Inc<br></span></font><div style=3D"margin-top: 0px; margin-=
bottom: 0px;"><font face=3D".HelveticaNeueInterface-M3"><span style=3D"font-=
size: 17px; -webkit-text-size-adjust: none; background-color: rgba(255, 255,=
 255, 0);"><a style=3D"outline: none;"></a><a href=3D"tel:619.850.8624" x-ap=
ple-data-detectors=3D"true" x-apple-data-detectors-type=3D"telephone" x-appl=
e-data-detectors-result=3D"0">6</a><a href=3D"tel:619.850.8624" x-apple-data=
-detectors=3D"true" x-apple-data-detectors-type=3D"telephone" x-apple-data-d=
etectors-result=3D"0">19.850.8624</a>&nbsp;|&nbsp;<a href=3D"http://airbitz.=
co/" target=3D"_blank" style=3D"outline: none;">http://airbitz.co</a>&nbsp;|=
&nbsp;San Diego</span></font></div><div style=3D"margin-top: 5px;"><font col=
or=3D"#000000" face=3D".HelveticaNeueInterface-M3"><span style=3D"font-size:=
 17px; -webkit-text-size-adjust: none; background-color: rgba(255, 255, 255,=
 0);"><a href=3D"http://facebook.com/airbitz" target=3D"_blank" style=3D"out=
line: none;"><img src=3D"http://images.wisestamp.com/facebook.png" width=3D"=
16" style=3D"border: none;"></a>&nbsp;<a href=3D"http://twitter.com/airbitz"=
 target=3D"_blank" style=3D"outline: none;"><img src=3D"http://images.wisest=
amp.com/twitter.png" width=3D"16" alt=3D"" style=3D"border: none;"></a>&nbsp=
;<a href=3D"https://plus.google.com/118173667510609425617" target=3D"_blank"=
 style=3D"outline: none;"><img src=3D"http://images.wisestamp.com/googleplus=
.png" width=3D"16" style=3D"border: none;"></a>&nbsp;<a href=3D"https://go.a=
irbitz.co/comments/feed/" target=3D"_blank" style=3D"outline: none;"><img sr=
c=3D"http://images.wisestamp.com/blogRSS.png" width=3D"16" style=3D"border: n=
one;"></a>&nbsp;<a href=3D"http://linkedin.com/in/paulpuey" target=3D"_blank=
" style=3D"outline: none;"><img src=3D"http://images.wisestamp.com/linkedin.=
png" width=3D"16" alt=3D"" style=3D"border: none;"></a>&nbsp;<a href=3D"http=
s://angel.co/paul-puey" target=3D"_blank" style=3D"outline: none;"><img src=3D=
"http://images.wisestamp.com/angelList.png" width=3D"16" alt=3D"" style=3D"b=
order: none;"></a></span></font></div></td></tr></tbody></table><table borde=
r=3D"0" style=3D"-webkit-text-size-adjust: auto; font-size: medium; font-fam=
ily: Helvetica, Arial, sans-serif;"><tbody><tr valign=3D"top"><td style=3D"w=
idth: auto; vertical-align: top;"><br></td><td><br></td></tr></tbody></table=
></div><div><br>On Feb 5, 2015, at 3:34 PM, Roy Badami &lt;<a href=3D"mailto=
:roy@gnomon.org.uk">roy@gnomon.org.uk</a>&gt; wrote:<br><br></div><div><span=
>For peer-to-peer payments, how common do we think that the payment is</span=
><br><span>of an ad hoc nature rather than to a known contact?</span><br><sp=
an></span><br><span>If I want to pay my friends/colleagues/etc over a restau=
rant table</span><br><span>there's no reason why I couldn't already have the=
ir public keys in my</span><br><span>contact list - then it would be pretty s=
traightforward to have a</span><br><span>watertight mechanism where I would k=
now who I was paying. &nbsp;You could</span><br><span>probably even relative=
ly securely bootstrap a key exchange over SMS,</span><br><span>relying only o=
n the contacts already having each other in their</span><br><span>phonebooks=
.</span><br><span></span><br><span>As for comsumer-to-merchant transactions w=
here the merchant is a</span><br><span>bricks and mortar merchant, IMHO it a=
bsolutely has to be "pay that</span><br><span>terminal over there". &nbsp;It=
's the trust model we all currently use -</span><br><span>whether paying cas=
h or card - and it's the only trust model that works</span><br><span>IMHO (a=
nd customers and businesses alike are well aware of the risks</span><br><spa=
n>of a fraudster standing behind the counter pretending to be an</span><br><=
span>employee accepting payment - and by and large are pretty good at</span>=
<br><span>mitigating it). &nbsp;OTOH as we've discussed here before there ar=
e many</span><br><span>use cases where the custoemr doesn't actually know or=
 care about the</span><br><span>name of the shop or bar they walked into but=
 is pretty damn sure that</span><br><span>they need to make payment to the p=
erson over there behind the counter.</span><br><span></span><br><span>Grante=
d, there are cases taht dont' fall into either of the above -</span><br><spa=
n>but they're the cases that are (a) harder to figure out how to</span><br><=
span>authenticate and consequently (b) the use cases that are going to be</s=
pan><br><span>most subject to attempted fraud.</span><br><span></span><br><s=
pan>roy</span><br><span></span><br><span>On Thu, Feb 05, 2015 at 03:02:56PM -=
0800, William Swanson wrote:</span><br><blockquote type=3D"cite"><span>On Th=
u, Feb 5, 2015 at 2:10 PM, Eric Voskuil &lt;<a href=3D"mailto:eric@voskuil.o=
rg">eric@voskuil.org</a>&gt; wrote:</span><br></blockquote><blockquote type=3D=
"cite"><blockquote type=3D"cite"><span>A MITM can receive the initial broadc=
ast and then spoof it by jamming the</span><br></blockquote></blockquote><bl=
ockquote type=3D"cite"><blockquote type=3D"cite"><span>original. You then on=
ly see one.</span><br></blockquote></blockquote><blockquote type=3D"cite"><s=
pan></span><br></blockquote><blockquote type=3D"cite"><span>You are right, o=
f course. There is no way to make Bluetooth 100%</span><br></blockquote><blo=
ckquote type=3D"cite"><span>secure, since it is an over-the-air technology. Y=
ou could try securing</span><br></blockquote><blockquote type=3D"cite"><span=
>it using a CA or other identity server, but now you've excluded ad-hoc</spa=
n><br></blockquote><blockquote type=3D"cite"><span>person-to-person payments=
. Plus, you need an active internet</span><br></blockquote><blockquote type=3D=
"cite"><span>connection to reach the CA.</span><br></blockquote><blockquote t=
ype=3D"cite"><span></span><br></blockquote><blockquote type=3D"cite"><span>Y=
ou can try using proximity as a substitute for identity, like</span><br></bl=
ockquote><blockquote type=3D"cite"><span>requiring NFC to kick-start the con=
nection, but at that point you</span><br></blockquote><blockquote type=3D"ci=
te"><span>might as well use QR codes.</span><br></blockquote><blockquote typ=
e=3D"cite"><span></span><br></blockquote><blockquote type=3D"cite"><span>Thi=
s BIP is not trying to provide absolute bullet-proof security,</span><br></b=
lockquote><blockquote type=3D"cite"><span>since that's impossible given the p=
hysical limitations of the</span><br></blockquote><blockquote type=3D"cite">=
<span>Bluetooth technology. Instead, it's trying to provide the</span><br></=
blockquote><blockquote type=3D"cite"><span>best-possible security given thos=
e constraints. In exchange for this,</span><br></blockquote><blockquote type=
=3D"cite"><span>we get greatly enhanced usability in common scenarios.</span=
><br></blockquote><blockquote type=3D"cite"><span></span><br></blockquote><b=
lockquote type=3D"cite"><span>There are plenty of usable, real-world technol=
ogies with big security</span><br></blockquote><blockquote type=3D"cite"><sp=
an>holes. Anybody with lock-picking experience will tell you this, but</span=
><br></blockquote><blockquote type=3D"cite"><span>nobody is welding their fr=
ont door shut. The ability to go in and out</span><br></blockquote><blockquo=
te type=3D"cite"><span>is worth the security risk.</span><br></blockquote><b=
lockquote type=3D"cite"><span></span><br></blockquote><blockquote type=3D"ci=
te"><span>Bluetooth payments add a whole new dimension to real-world Bitcoin=
</span><br></blockquote><blockquote type=3D"cite"><span>usability. Do we shu=
t that down because it can't be made perfect, or</span><br></blockquote><blo=
ckquote type=3D"cite"><span>do we do the best we can and move forward?</span=
><br></blockquote><blockquote type=3D"cite"><span></span><br></blockquote><b=
lockquote type=3D"cite"><span>-William</span><br></blockquote><blockquote ty=
pe=3D"cite"><span></span><br></blockquote><blockquote type=3D"cite"><span>--=
----------------------------------------------------------------------------=
</span><br></blockquote><blockquote type=3D"cite"><span>Dive into the World o=
f Parallel Programming. The Go Parallel Website,</span><br></blockquote><blo=
ckquote type=3D"cite"><span>sponsored by Intel and developed in partnership w=
ith Slashdot Media, is your</span><br></blockquote><blockquote type=3D"cite"=
><span>hub for all things parallel software development, from weekly thought=
</span><br></blockquote><blockquote type=3D"cite"><span>leadership blogs to n=
ews, videos, case studies, tutorials and more. Take a</span><br></blockquote=
><blockquote type=3D"cite"><span>look and join the conversation now. <a href=
=3D"http://goparallel.sourceforge.net/">http://goparallel.sourceforge.net/</=
a></span><br></blockquote><blockquote type=3D"cite"><span>__________________=
_____________________________</span><br></blockquote><blockquote type=3D"cit=
e"><span>Bitcoin-development mailing list</span><br></blockquote><blockquote=
 type=3D"cite"><span><a href=3D"mailto:Bitcoin-development@lists.sourceforge=
.net">Bitcoin-development@lists.sourceforge.net</a></span><br></blockquote><=
blockquote type=3D"cite"><span><a href=3D"https://lists.sourceforge.net/list=
s/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo=
/bitcoin-development</a></span><br></blockquote><blockquote type=3D"cite"><s=
pan></span><br></blockquote></div></body></html>=

--Apple-Mail-32EFC4CE-12D4-4DF8-86EA-A859F42DA7F0--