summaryrefslogtreecommitdiff
path: root/5f/ab7edd48ae4e536dab6725eeafd896ca5abb80
blob: dea38b981cc815da5872dd31d03876e15f394edb (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
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
Return-Path: <ahmedzsales18@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id AAA75B50
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 24 Aug 2015 12:57:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f67.google.com (mail-vk0-f67.google.com
	[209.85.213.67])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2840F19C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 24 Aug 2015 12:57:47 +0000 (UTC)
Received: by vkfi73 with SMTP id i73so4639508vkf.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 24 Aug 2015 05:57:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=esd4MZvDkwCHjPtnt5pqj31e8LVbSlNIkbLZMTn7HJE=;
	b=PfdnsiWja0X9lzcpJWPDJPB2o1YMebQke1JW2uawhW3isOyeJCU3dgtq2J4IFt7uqn
	MNaMAHPsZUx2Rwp128tL+kOkbniw8AHAYGSmSPALHTnvhhSNvJFcp3vll+VeRmXx8Arw
	SaLxFcsbpx01mHCiUIzv1fTkK/pne5JnIIXuimOG1g30OPwHfD535K+CcMHY/JCKKdsY
	D2ZpWf8BksrfEA9hkzVeKVrPG5+CdBEwSw7B0elBN93txh/TEiAkP73LpCjzkbIgOvE/
	U1xdLCgVsJRzKEr9oV2b3BQhQOxglCF1dTQekoH7Vri+mium/Oxn2re1bB+XqV4PKtyN
	T/Yg==
MIME-Version: 1.0
X-Received: by 10.52.109.193 with SMTP id hu1mr24302822vdb.6.1440421066189;
	Mon, 24 Aug 2015 05:57:46 -0700 (PDT)
Received: by 10.31.109.134 with HTTP; Mon, 24 Aug 2015 05:57:46 -0700 (PDT)
In-Reply-To: <CALqxMTFixvQGTqLogDzrv0zhQFH6Z5kBdG9zwqoMuhjPvJadsg@mail.gmail.com>
References: <CALqxMTFixvQGTqLogDzrv0zhQFH6Z5kBdG9zwqoMuhjPvJadsg@mail.gmail.com>
Date: Mon, 24 Aug 2015 13:57:46 +0100
Message-ID: <CADr=VrTE90CCsd0dv1sFfB0YiexA3Ew1V=hX-imEAvHtHgyzog@mail.gmail.com>
From: Ahmed Zsales <ahmedzsales18@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=bcaec548a15bfa2fe6051e0e29ee
X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_20,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] BIP 10X: Replace Transaction Fees with Data,
 Discussion Draft 0.2.9
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Aug 2015 12:57:48 -0000

--bcaec548a15bfa2fe6051e0e29ee
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Adam,

Thank you for your comments. We will address them in the next update.

Privacy is an area you have been championing for many years and your input
in this area has created the environment for Bitcoin to exist. Anonymity is
not something we would be willing to compromise, despite the general
public's endless willingness to give away their intimate life histories and
contact details to Facebook and other social media.

If you have the will to read a longish response, we have tried to expand a
little on the rationale for the type of data we believe will be useful and
valuable, in addition to broadly addressing the privacy issues.

Arguably, the greater the cryptographic protections on the ownership of a
transaction, the more value will be placed on the nature of transactions.
Without wishing to frame the conversation on specifics or particular
sectors, here are some distinctions to address some of the previously noted
Orwellian fears on attaching identity markers to Bitcoin transactions.

* We have no desire to create tools that can analyze which brand of baked
beans Bob may prefer compared to Alice. That is a matter of extreme detail
for supermarkets, their suppliers and internal point of sale systems.  When
you make a store purchase, your basket of goods are wrapped up in a single
payment which appears on your credit card or bank statement. Knowing on an
aggregated basis that people spend around $120 / week on retail shopping
and that Saturday is the busiest period for that activity is more valuable
for payment processors than knowing the contents of Bob's basket of goods.

As a retailer or supplier, I would buy that data in order to plan
inventory, marketing budgets, promotional activity, staffing levels,
logistics, factory production, bank borrowing, store expansion planning,
etc.

* Now consider petrol. Bitcoin is very well suited for fuel purchases,
especially for small independent petrol filling stations. Aggregated data
would help the entire supply chain that serves the consumer, if businesses
at the front end had access to data for when demand was at peaks and
troughs. Extend that from individual petrol stations to regional, national
and international consumer purchases and you have the basis of the market
pricing oil based on demand per period and per country. Again, we don't
care that it is actually Bob who fills up every Sunday so he has enough
fuel to last him the week or to track him along his driving holiday.

* Now consider remittances. While the global headlines are that it is a
$500bn a year industry. Few people know that remittances are based on a
relatively small number of remittance corridors that make up the bulk of
the market.  These corridors are based around people leaving small towns
and villages in poor areas and travelling to work in locations based on
knowing someone or a family member who used to live in their area and are
doing well in xyz location because they can see the beneficial impact on
the recipients quality of life. At the coal face, remittances are a word of
mouth grey market sector and part of the reason that WU and the like can
charge so much is because the last mile of remittances are in areas where
monetary infrastructure and logistics are difficult to serve and they can
get away with setting high prices. They prosper because they use data to
organise themselves better. Banks have no desire to serve this market
because you end up clogging up branches every Friday or Saturday with
people that transact relatively small sums compared to those that are
banked and get annoyed waiting. Having access to Bitcoin transaction data
on this sector would help Bitcoin businesses to understand the end points
of this market and serve it better and focus their promotional activities.
We have no desire to identify that Bob's cousin Jos=C3=A9 is working illega=
lly
in Texas.

These are three sectors where there are millions of small businesses that
would, for the first time, be able to access global, national and regional
industry data figures typically reserved for large businesses due to the
high cost of acquiring or commissioning research.

While increasing anonymity or having zero knowledge proofs in transactions
is desirable so that I can keep my Bitcoin salary payments private and my
membership of Ashley Madison out of the news, it would be helpful to know
that when I want to spend my salary that the world around me is organised
enough to serve my needs.

The block chain is ledger. It will contain a global data set that could end
up being one of the most valuable databases in the world. Why not use it to
fund Bitcoin's security infrastructure and growing bandwidth challenges?

Regards,

Ahmed






On Sun, Aug 23, 2015 at 5:05 PM, Adam Back <adam@cypherspace.org> wrote:

> Some comments:
>
> "(i) remove any possibility of free transactions unless
>
> associated with basic transaction data;"
>
> I believe it is not possible to prevent free transactions for the
> reason that people can pay out of band (via existing banking transfers
> to miners) or make payments to addresses belonging to miners (that are
> contingent on the requested user transaction being processed via input
> dependency) .
>
>
> I am not sure I fully understand the way you see monetisation working,
> and you do indicate this is quite far future what-if stage idea, and
> you do identify a conflict with fungibility - but I think this is
> probably quite badly in conflict with fungibility to the point of
> conflicting with many planned Bitcoin improvements?  And mid term
> technical directions.
>
> I would say the long term idealised requirements are that the
> transaction itself would have cryptographic fungibility, and policy
> relating to identity for authorisation, approval in regulated
> transactions would take place at the payment protocol layer.  The
> payment protocol is already seeing some use.
>
> Lightning protocol sees more of the data going point to point and so
> not broadcast nor visible for big data analytic monetisation.
>
> Adam
>
> On 22 August 2015 at 23:51, Jorge Tim=C3=B3n
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Again, did you got a bip number asigned or did you self-assigned it
> yourself?
> >
> > On Sat, Aug 22, 2015 at 1:01 PM, Ahmed Zsales via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >> Hello,
> >>
> >> In response to public and private comments and feedback, we have updat=
ed
> >> this working draft.
> >>
> >>
> https://drive.google.com/file/d/0BwEbhrQ4ELzBOUVtOHJQdlhvUmc/view?usp=3Ds=
haring
> >>
> >> Update highlights:
> >>
> >> 1. Specific clarifications on replacing the Coinbase subsidy and
> >> supplementing and not replacing transaction fees.
> >>
> >> 2. Clarification on block chain overhead. The value of data mining is
> on a
> >> bell curve, so year six data will be removed every year.
> >>
> >> 3. Added references to an ability to create global, national and
> regional
> >> Bitcoin Price Indices for popular baskets of goods transacted with
> Bitcoin.
> >>
> >> 4. Added references for an ability to use structured block chain data
> for
> >> Bitcoin capacity and fork planning.
> >>
> >> 5. Removed references to price speculation.
> >>
> >> 6. Added preferences for deployment dates of January 2017 or January
> 2018.
> >>
> >> 7. Moving towards BIP format after discussion and evaluation period.
> >> Technical content will increase in due course and discussion content
> will be
> >> removed.
> >>
> >> Further views and feedback welcome.
> >>
> >> Regards,
> >>
> >> Ahmed
> >>
> >>
> >> On Mon, Aug 17, 2015 at 5:23 PM, Ahmed Zsales <ahmedzsales18@gmail.com=
>
> >> wrote:
> >>>
> >>> Hello,
> >>>
> >>> Here we propose a long-term solution to replace mining rewards and
> >>> transactions fees.
> >>>
> >>> BIP 104 is currently a discussion draft only.
> >>>
> >>>
> >>>
> https://drive.google.com/file/d/0BwEbhrQ4ELzBSXpoUjRkc01QUGc/view?usp=3Ds=
haring
> >>>
> >>> Views and feedback welcome.
> >>>
> >>> Regards,
> >>>
> >>> Ahmed
> >>>
> >>
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--bcaec548a15bfa2fe6051e0e29ee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Adam,=C2=A0</div><div><br></div><div>Thank you for yo=
ur comments. We will address them in the next update.=C2=A0</div><div><br><=
/div>Privacy is an area you have been championing for many years and your i=
nput in this area has created the environment for Bitcoin to exist. Anonymi=
ty is not something we would be willing to compromise, despite the general =
public&#39;s endless willingness to give away their intimate life histories=
 and contact details to Facebook and other social media.=C2=A0<div><br></di=
v><div>If you have the will to read a longish response, we have tried to ex=
pand a little on the rationale for the type of data we believe will be usef=
ul and valuable, in addition to broadly addressing the privacy issues.</div=
><div><br></div><div>Arguably, the greater the cryptographic protections on=
 the ownership of a transaction, the more value will be placed on the natur=
e of transactions. Without wishing to frame the conversation on specifics o=
r particular sectors, here are some distinctions to address some of the pre=
viously noted Orwellian fears on attaching identity markers to Bitcoin tran=
sactions.=C2=A0</div><div><br></div><div>* We have no desire to create tool=
s that can analyze which brand of baked beans Bob may prefer compared to Al=
ice. That is a matter of extreme detail for supermarkets, their suppliers a=
nd internal point of sale systems.=C2=A0 When you make a store purchase, yo=
ur basket of goods are wrapped up in a single payment which appears on your=
 credit card or bank statement. Knowing on an aggregated basis that people =
spend around $120 / week on retail shopping and that Saturday is the busies=
t period for that activity is more valuable for payment processors than kno=
wing the contents of Bob&#39;s basket of goods.</div><div><br></div><div>As=
 a retailer or supplier, I would buy that data in order to plan inventory, =
marketing budgets, promotional activity, staffing levels, logistics, factor=
y production, bank borrowing, store expansion planning, etc.</div><div><br>=
</div><div>* Now consider petrol. Bitcoin is very well suited for fuel purc=
hases, especially for small independent petrol filling stations. Aggregated=
 data would help the entire supply chain that serves the consumer, if busin=
esses at the front end had access to data for when demand was at peaks and =
troughs. Extend that from individual petrol stations to regional, national =
and international consumer purchases and you have the basis of the market p=
ricing oil based on demand per period and per country. Again, we don&#39;t =
care that it is actually Bob who fills up every Sunday so he has enough fue=
l to last him the week or to track him along his driving holiday.</div><div=
><br></div><div>* Now consider remittances. While the global headlines are =
that it is a $500bn a year industry. Few people know that remittances are b=
ased on a relatively small number of remittance corridors that make up the =
bulk of the market.=C2=A0 These corridors are based around people leaving s=
mall towns and villages in poor areas and travelling to work in locations b=
ased on knowing someone or a family member who used to live in their area a=
nd are doing well in xyz location because they can see the beneficial impac=
t on the recipients quality of life. At the coal face, remittances are a wo=
rd of mouth grey market sector and part of the reason that WU and the like =
can charge so much is because the last mile of remittances are in areas whe=
re monetary infrastructure and logistics are difficult to serve and they ca=
n get away with setting high prices. They prosper because they use data to =
organise themselves better. Banks have no desire to serve this market becau=
se you end up clogging up branches every Friday or Saturday with people tha=
t transact relatively small sums compared to those that are banked and get =
annoyed waiting. Having access to Bitcoin transaction data on this sector w=
ould help Bitcoin businesses to understand the end points of this market an=
d serve it better and focus their promotional activities. We have no desire=
 to identify that Bob&#39;s cousin Jos=C3=A9 is working illegally in Texas.=
</div><div><br></div><div>These are three sectors where there are millions =
of small businesses that would, for the first time, be able to access globa=
l, national and regional industry data figures typically reserved for large=
 businesses due to the high cost of acquiring or commissioning research.=C2=
=A0</div><div><br></div><div>While increasing anonymity or having zero know=
ledge proofs in transactions is desirable so that I can keep my Bitcoin sal=
ary payments private and my membership of Ashley Madison out of the news, i=
t would be helpful to know that when I want to spend my salary that the wor=
ld around me is organised enough to serve my needs.</div><div><br></div><di=
v>The block chain is ledger. It will contain a global data set that could e=
nd up being one of the most valuable databases in the world. Why not use it=
 to fund Bitcoin&#39;s security infrastructure and growing bandwidth challe=
nges?=C2=A0</div><div><br></div><div>Regards,<br></div><div><br></div><div>=
Ahmed</div><div><br></div><div><br></div><div><br></div><div><br></div><div=
><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Sun, Aug 23, 2015 at 5:05 PM, Adam Back <span dir=3D"ltr">&lt;<a href=3D=
"mailto:adam@cypherspace.org" target=3D"_blank">adam@cypherspace.org</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">Some comments:<br>
<br>
&quot;(i) remove any possibility of free transactions unless<br>
<br>
associated with basic transaction data;&quot;<br>
<br>
I believe it is not possible to prevent free transactions for the<br>
reason that people can pay out of band (via existing banking transfers<br>
to miners) or make payments to addresses belonging to miners (that are<br>
contingent on the requested user transaction being processed via input<br>
dependency) .<br>
<br>
<br>
I am not sure I fully understand the way you see monetisation working,<br>
and you do indicate this is quite far future what-if stage idea, and<br>
you do identify a conflict with fungibility - but I think this is<br>
probably quite badly in conflict with fungibility to the point of<br>
conflicting with many planned Bitcoin improvements?=C2=A0 And mid term<br>
technical directions.<br>
<br>
I would say the long term idealised requirements are that the<br>
transaction itself would have cryptographic fungibility, and policy<br>
relating to identity for authorisation, approval in regulated<br>
transactions would take place at the payment protocol layer.=C2=A0 The<br>
payment protocol is already seeing some use.<br>
<br>
Lightning protocol sees more of the data going point to point and so<br>
not broadcast nor visible for big data analytic monetisation.<br>
<br>
Adam<br>
<br>
On 22 August 2015 at 23:51, Jorge Tim=C3=B3n<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>&gt; wrote:<br>
&gt; Again, did you got a bip number asigned or did you self-assigned it yo=
urself?<br>
&gt;<br>
&gt; On Sat, Aug 22, 2015 at 1:01 PM, Ahmed Zsales via bitcoin-dev<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt; Hello,<br>
&gt;&gt;<br>
&gt;&gt; In response to public and private comments and feedback, we have u=
pdated<br>
&gt;&gt; this working draft.<br>
&gt;&gt;<br>
&gt;&gt; <a href=3D"https://drive.google.com/file/d/0BwEbhrQ4ELzBOUVtOHJQdl=
hvUmc/view?usp=3Dsharing" rel=3D"noreferrer" target=3D"_blank">https://driv=
e.google.com/file/d/0BwEbhrQ4ELzBOUVtOHJQdlhvUmc/view?usp=3Dsharing</a><br>
&gt;&gt;<br>
&gt;&gt; Update highlights:<br>
&gt;&gt;<br>
&gt;&gt; 1. Specific clarifications on replacing the Coinbase subsidy and<b=
r>
&gt;&gt; supplementing and not replacing transaction fees.<br>
&gt;&gt;<br>
&gt;&gt; 2. Clarification on block chain overhead. The value of data mining=
 is on a<br>
&gt;&gt; bell curve, so year six data will be removed every year.<br>
&gt;&gt;<br>
&gt;&gt; 3. Added references to an ability to create global, national and r=
egional<br>
&gt;&gt; Bitcoin Price Indices for popular baskets of goods transacted with=
 Bitcoin.<br>
&gt;&gt;<br>
&gt;&gt; 4. Added references for an ability to use structured block chain d=
ata for<br>
&gt;&gt; Bitcoin capacity and fork planning.<br>
&gt;&gt;<br>
&gt;&gt; 5. Removed references to price speculation.<br>
&gt;&gt;<br>
&gt;&gt; 6. Added preferences for deployment dates of January 2017 or Janua=
ry 2018.<br>
&gt;&gt;<br>
&gt;&gt; 7. Moving towards BIP format after discussion and evaluation perio=
d.<br>
&gt;&gt; Technical content will increase in due course and discussion conte=
nt will be<br>
&gt;&gt; removed.<br>
&gt;&gt;<br>
&gt;&gt; Further views and feedback welcome.<br>
&gt;&gt;<br>
&gt;&gt; Regards,<br>
&gt;&gt;<br>
&gt;&gt; Ahmed<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Mon, Aug 17, 2015 at 5:23 PM, Ahmed Zsales &lt;<a href=3D"mailt=
o:ahmedzsales18@gmail.com">ahmedzsales18@gmail.com</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Hello,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Here we propose a long-term solution to replace mining rewards=
 and<br>
&gt;&gt;&gt; transactions fees.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; BIP 104 is currently a discussion draft only.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; <a href=3D"https://drive.google.com/file/d/0BwEbhrQ4ELzBSXpoUj=
Rkc01QUGc/view?usp=3Dsharing" rel=3D"noreferrer" target=3D"_blank">https://=
drive.google.com/file/d/0BwEbhrQ4ELzBSXpoUjRkc01QUGc/view?usp=3Dsharing</a>=
<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Views and feedback welcome.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Regards,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Ahmed<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.linuxfoundation.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a><br>
&gt;&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>

--bcaec548a15bfa2fe6051e0e29ee--