summaryrefslogtreecommitdiff
path: root/b6/34ff86bd548d5d05056330c315e684397559f3
blob: 93d26c794b50bb27378443b39f1d89faef67d26d (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
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
Return-Path: <contact@taoeffect.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id ED4E7ABB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Jul 2017 22:41:22 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from homiemail-a3.g.dreamhost.com (homie.mail.dreamhost.com
	[208.97.132.208])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6D08610A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Jul 2017 22:41:21 +0000 (UTC)
Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1])
	by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id CABA0284087;
	Tue, 11 Jul 2017 15:41:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=taoeffect.com; h=
	content-type:mime-version:subject:from:in-reply-to:date:cc
	:message-id:references:to; s=taoeffect.com; bh=VfnryU3nwBF1ajbfp
	zl9N+sI20g=; b=HtdKWd8jiIMWK7vkSHd2yo4DpQtE9zIZSfAPv5Jq9Taw2D3YC
	t+dvoYF9SM/BSiOYPEdT0Or+YST1pvkZJfGd/4xHbju5jdl+uTQ6MaPiHv4hM/zQ
	5qbuyW5cvY1peyn9pMUj80H/cEGaryUjaktAEntR50GPrqBubl334lSojA=
Received: from [192.168.42.67] (184-23-252-118.fiber.dynamic.sonic.net
	[184.23.252.118])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: contact@taoeffect.com)
	by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPSA id 4EECC28406C; 
	Tue, 11 Jul 2017 15:41:20 -0700 (PDT)
Content-Type: multipart/signed;
	boundary="Apple-Mail=_469E18AE-6CAA-4425-AE12-DE90ECAF00FF";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Tao Effect <contact@taoeffect.com>
In-Reply-To: <1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
Date: Tue, 11 Jul 2017 15:41:18 -0700
X-Mao-Original-Outgoing-Id: 521505678.763297-93f4bc69500ce70f97094074eda34c54
Message-Id: <A030CDEA-CB0F-40BF-9404-6BD091537BE1@taoeffect.com>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
	<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
To: Paul Sztorc <truthcoin@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 11 Jul 2017 22:44:10 +0000
Subject: Re: [bitcoin-dev] Updating the Scaling Roadmap
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Tue, 11 Jul 2017 22:41:23 -0000


--Apple-Mail=_469E18AE-6CAA-4425-AE12-DE90ECAF00FF
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_08DB5B61-10CC-4F59-B819-AA7B5338478F"


--Apple-Mail=_08DB5B61-10CC-4F59-B819-AA7B5338478F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Dear Paul,

Drivechain has several issues that you've acknowledged but have not, =
IMO, adequately (at all really) addressed [1].

I think there are far safer solutions for scaling Bitcoin and =
integrating it with other chains than DC, which is again, a serious =
security risk to the whole network, as per [1].

Adopting DC would be an irreversible course of action, and one that in =
my opinion would unnecessarily damage not only other sidechains, but the =
main chain as well.

There is no rush, a proper solution is likely to present itself (I even =
have one that I'm toying with, but it's not quite ready yet for =
publication). I'm sure others are thinking similar thoughts too.

Kind regards,
Greg Slepak

[1] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.h=
tml =
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014600.=
html>

--
Please do not email me anything that you are not comfortable also =
sharing with the NSA.

> On Jul 11, 2017, at 3:17 PM, Paul Sztorc via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>=20
> Hi Greg,
>=20
>=20
> On 7/11/2017 5:11 PM, Gregory Maxwell wrote:
>> I think it's great that people want to experiment with things like
>> drivechains/sidechains and what not, but their security model is very
>> distinct from Bitcoin's and, given the current highly centralized
>> mining ecosystem, arguably not very good.  So positioning them as a
>> major solution for the Bitcoin project is the wrong way to go. =
Instead
>> we should support people trying cool stuff, at their own risk.
>>=20
>> So, given that although the vast majority of the things in the =
document
>> are things I've been supporting for months (Please see Note 1 way =
down
>> at the bottom) I cannot support your document.
> Is this the only reason you do not support the document? If so I would
> be happy to take out the section, if enough people share such a view.
>=20
> As to your specific complaints, I have addressed both the security =
model
> and the concept of mining centralization on this list in the recent
> past. I would like to hear your responses to my claims, if you are
> willing to share them. As for positioning DC as a major solution, it =
is
> a little confusing because Luke-Jr and Adam back seem to feel it is at
> least worth discussing on those terms (and I know of no reason why it
> would not be discussed on those terms). The peer review here on
> [bitcoin-dev] seemed to be moving forward without any serious
> objections. And it seems unsportsmanlike for you to object, for =
reasons
> which you keep only to yourself.
>=20
>=20
>> On a more meta-subject, I think grandly stated "top down" roadmaps
>> in highly collaborative development are of minimal utility at best
> I'm aiming for minimal utility.
>=20
>> IMO the way to do "roadmaps" in Bitcoin is to roadmap the =
finalization
>> and release process once the basic technology is done; because it's
>> only past that point that guarantees can really start being made.
>>=20
>> But that isn't what your document does-- it names a lot of things =
which
>> are still various shades of research at this point
> I don't understand this at all. This document attempts to do exactly
> what its predecessor did -- nothing more or less.
>=20
>> This was an incredible benefit to our customers, but the only way it =
was
>> possible was because _features_ were not guaranteed in a release.
> No one is suggesting that features be guaranteed, either ever or in
> releases.
>=20
>=20
>> One of the big screwups with segwit handling was people sticking
>> some random unrealistic date on it it which was done AFAIK,
>> by well meaning folks who took some random numbers from people
>> working on it for when they'd be done with the development-- not the
>> testing, not the integration, and certainly not deployment and =
published
>> it as The Date.  Then even though the development was actually done
>> by them, segwit was portrayed as massively delayed, because what
>> matters to the users is deployment-- which we can't control.
> I really don't think they are related. For a start, software is almost
> always delayed. An obvious second is that this entire scaling
> conversation is polarized to the hilt and everyone that can be blamed
> for something has been blamed for something.
>=20
> No one likes to be held to a certain deadline, but this roadmap is =
just
> about producing some clarity for people who do not do this 24/7.
>=20
>> I see you've done this yourself with signature aggregation, sticking =
Q4 2016
>> right on it, which as far as I can tell is a figure that comes from =
mars.
> I asked Adam Back for it.
>=20
>> It's also not really appropriate to ask people to sign onto stuff =
when they
>> can't even review it.  Perhaps the signature aggregation stuff is =
insecure,
>> patent encumbered, or practically useless... (It won't be but no one =
could
>> tell that from your post; because it doesn't even exist as a concrete =
proposal)
> Again, I think you're missing the point. If there is a problem with =
SA,
> you can just suggest it be removed from the document.
>=20
>=20
>> I think people would rightly protest about a number of these things-- =
especially
>> things like the the agg sigs and tx compaction, "wtf, I've not heard
>> of this. Who
>> are you to insist this goes into Bitcoin?"
> This is a very strange argument. I would consider it a benefit if =
people
> learned from the document, and discovered things that they had not =
heard
> of before.
>=20
> There is no "insisting" of any kind.
>=20
>=20
>> [  Note 1: I think it is important to disclose that several of the
>> items in this list appear to be more or less quoted out of my own
>> blockstream-internal descriptions of things we've been working on in
>> Bitcoin.
>> A while back Adam Back asked me to publish something which contained
>> significant chunks of this document more or less verbatim,
> He probably showed you an earlier draft. But I wrote almost all of =
this
> myself, and I can only recall 2 or 3 phrases (not even complete
> sentences) included from Adam Back. And most of the phrases are
> themselves just boring descriptions that I'm sure anyone could write.
> Some phrases may have simply been taken from bitcoincore.org =
<http://bitcoincore.org/> or
> somewhere similar.
>=20
> I am not exactly sure what you are insinuating but I encourage you to
> clarify it.
>=20
>> and I
>> declined saying that I personally disagree with some of his points =
and
>> didn't think that Blockstream attempting to redirect the Bitcoin
>> project (esp towards drivechains) was appropriate-- along with my
>> (above) views on roadmaps (which I have included here a private email
>> thread on the subject). I feel it's important to disclose this, and
>> that the document was not otherwise created with the input of project
>> contributors (except Luke-Jr, apparently). I wasn't previously aware
>> that Adam had been working with Paul on this, had I been I would have
>> also encouraged people to be a little more transparent about it. ]
> I really don't understand what you are disclosing. That Adam asked you
> for feedback on the draft? And then, in the next sentence, that not
> enough experts were asked for feedback on the draft? I'm legitimately
> confused by this part.
>=20
> As I stated, we can remove the drivechain section. But surely you can
> appreciate how bizarre your position on roadmaps is. What exactly, did
> you intended to create at [1]? Since it is described explicitly as =
"the
> roadmap in Capacity increases for the Bitcoin system", have you been
> disagreeing with it's characterization as a 'roadmap' this entire =
time?
> One wonders why you haven't said anything until now.
>=20
> [1] https://bitcoincore.org/en/2015/12/21/capacity-increase/ =
<https://bitcoincore.org/en/2015/12/21/capacity-increase/>
>=20
> In my first email I list the benefits of having a roadmap. One benefit
> is that, without one, it is likely that a large majority of outsiders
> have almost no idea at all what is being worked on, what effect it =
will
> have, or when it might be ready, or to whom/what they should turn to =
for
> advice on such matters. Do you have a different way of addressing this
> communication problem?
>=20
> Paul
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_08DB5B61-10CC-4F59-B819-AA7B5338478F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"><meta http-equiv=3D"Content-Type" content=3D"text/html=
 charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">Dear Paul,<div class=3D""><br class=3D""></div><div =
class=3D"">Drivechain has several issues that you've acknowledged but =
have not, IMO, adequately (at all really) addressed [1].</div><div =
class=3D""><br class=3D""></div><div class=3D"">I think there are far =
safer solutions for scaling Bitcoin and integrating it with other chains =
than DC, which is again, a serious security risk to the whole network, =
as per [1].</div><div class=3D""><br class=3D""></div><div =
class=3D"">Adopting DC would be an irreversible course of action, and =
one that in my opinion would unnecessarily damage not only other =
sidechains, but the main chain as well.</div><div class=3D""><br =
class=3D""></div><div class=3D"">There is no rush, a proper solution is =
likely to present itself (I even have one that I'm toying with, but it's =
not quite ready yet for publication). I'm sure others are thinking =
similar thoughts too.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Kind regards,</div><div class=3D"">Greg Slepak</div><div =
class=3D""><br class=3D""></div><div class=3D"">[1]&nbsp;<a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/=
014600.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Ju=
ne/014600.html</a></div><div class=3D""><div class=3D""><div class=3D"">
<span style=3D"color: rgb(0, 0, 0); font-family: Helvetica; font-size: =
14px; font-style: normal; font-variant-caps: normal; font-weight: =
normal; letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; font-variant-ligatures: normal; =
font-variant-position: normal; font-variant-numeric: normal; =
font-variant-alternates: normal; font-variant-east-asian: normal; =
line-height: normal; orphans: 2; widows: 2;" class=3D""><br =
class=3D"Apple-interchange-newline">--</span><br style=3D"color: rgb(0, =
0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
font-variant-ligatures: normal; font-variant-position: normal; =
font-variant-numeric: normal; font-variant-alternates: normal; =
font-variant-east-asian: normal; line-height: normal; orphans: 2; =
widows: 2;" class=3D""><span style=3D"color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 14px; font-style: normal; font-variant-caps: =
normal; font-weight: normal; letter-spacing: normal; text-align: start; =
text-indent: 0px; text-transform: none; white-space: normal; =
word-spacing: 0px; -webkit-text-stroke-width: 0px; =
font-variant-ligatures: normal; font-variant-position: normal; =
font-variant-numeric: normal; font-variant-alternates: normal; =
font-variant-east-asian: normal; line-height: normal; orphans: 2; =
widows: 2;" class=3D"">Please do not email me anything that you are not =
comfortable also sharing</span><span style=3D"color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 14px; font-style: normal; =
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; =
text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
font-variant-ligatures: normal; font-variant-position: normal; =
font-variant-numeric: normal; font-variant-alternates: normal; =
font-variant-east-asian: normal; line-height: normal; orphans: 2; =
widows: 2;" class=3D"">&nbsp;with the NSA.</span>
</div>
<br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Jul 11, 2017, at 3:17 PM, Paul Sztorc via bitcoin-dev =
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">Hi =
Greg,<br class=3D""><br class=3D""><br class=3D"">On 7/11/2017 5:11 PM, =
Gregory Maxwell wrote:<br class=3D""><blockquote type=3D"cite" =
class=3D"">I think it's great that people want to experiment with things =
like<br class=3D"">drivechains/sidechains and what not, but their =
security model is very<br class=3D"">distinct from Bitcoin's and, given =
the current highly centralized<br class=3D"">mining ecosystem, arguably =
not very good. &nbsp;So positioning them as a<br class=3D"">major =
solution for the Bitcoin project is the wrong way to go. Instead<br =
class=3D"">we should support people trying cool stuff, at their own =
risk.<br class=3D""><br class=3D"">So, given that although the vast =
majority of the things in the document<br class=3D"">are things I've =
been supporting for months (Please see Note 1 way down<br class=3D"">at =
the bottom) I cannot support your document.<br class=3D""></blockquote>Is =
this the only reason you do not support the document? If so I would<br =
class=3D"">be happy to take out the section, if enough people share such =
a view.<br class=3D""><br class=3D"">As to your specific complaints, I =
have addressed both the security model<br class=3D"">and the concept of =
mining centralization on this list in the recent<br class=3D"">past. I =
would like to hear your responses to my claims, if you are<br =
class=3D"">willing to share them. As for positioning DC as a major =
solution, it is<br class=3D"">a little confusing because Luke-Jr and =
Adam back seem to feel it is at<br class=3D"">least worth discussing on =
those terms (and I know of no reason why it<br class=3D"">would not be =
discussed on those terms). The peer review here on<br =
class=3D"">[bitcoin-dev] seemed to be moving forward without any =
serious<br class=3D"">objections. And it seems unsportsmanlike for you =
to object, for reasons<br class=3D"">which you keep only to yourself.<br =
class=3D""><br class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D"">On a more meta-subject, I think grandly stated "top down" =
roadmaps<br class=3D"">in highly collaborative development are of =
minimal utility at best <br class=3D""></blockquote>I'm aiming for =
minimal utility.<br class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D"">IMO the way to do "roadmaps" in Bitcoin is to roadmap the =
finalization<br class=3D"">and release process once the basic technology =
is done; because it's<br class=3D"">only past that point that guarantees =
can really start being made.<br class=3D""><br class=3D"">But that isn't =
what your document does-- it names a lot of things which<br class=3D"">are=
 still various shades of research at this point<br =
class=3D""></blockquote>I don't understand this at all. This document =
attempts to do exactly<br class=3D"">what its predecessor did -- nothing =
more or less.<br class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D"">This was an incredible benefit to our customers, but the only =
way it was<br class=3D"">possible was because _features_ were not =
guaranteed in a release.<br class=3D""></blockquote>No one is suggesting =
that features be guaranteed, either ever or in<br class=3D"">releases.<br =
class=3D""><br class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D"">One of the big screwups with segwit handling was people =
sticking<br class=3D"">some random unrealistic date on it it which was =
done AFAIK,<br class=3D"">by well meaning folks who took some random =
numbers from people<br class=3D"">working on it for when they'd be done =
with the development-- not the<br class=3D"">testing, not the =
integration, and certainly not deployment and published<br class=3D"">it =
as The Date. &nbsp;Then even though the development was actually done<br =
class=3D"">by them, segwit was portrayed as massively delayed, because =
what<br class=3D"">matters to the users is deployment-- which we can't =
control.<br class=3D""></blockquote>I really don't think they are =
related. For a start, software is almost<br class=3D"">always delayed. =
An obvious second is that this entire scaling<br class=3D"">conversation =
is polarized to the hilt and everyone that can be blamed<br class=3D"">for=
 something has been blamed for something.<br class=3D""><br class=3D"">No =
one likes to be held to a certain deadline, but this roadmap is just<br =
class=3D"">about producing some clarity for people who do not do this =
24/7.<br class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">I =
see you've done this yourself with signature aggregation, sticking Q4 =
2016<br class=3D"">right on it, which as far as I can tell is a figure =
that comes from mars.<br class=3D""></blockquote>I asked Adam Back for =
it.<br class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">It's=
 also not really appropriate to ask people to sign onto stuff when =
they<br class=3D"">can't even review it. &nbsp;Perhaps the signature =
aggregation stuff is insecure,<br class=3D"">patent encumbered, or =
practically useless... (It won't be but no one could<br class=3D"">tell =
that from your post; because it doesn't even exist as a concrete =
proposal)<br class=3D""></blockquote>Again, I think you're missing the =
point. If there is a problem with SA,<br class=3D"">you can just suggest =
it be removed from the document.<br class=3D""><br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">I think people would =
rightly protest about a number of these things-- especially<br =
class=3D"">things like the the agg sigs and tx compaction, "wtf, I've =
not heard<br class=3D"">of this. Who<br class=3D"">are you to insist =
this goes into Bitcoin?"<br class=3D""></blockquote>This is a very =
strange argument. I would consider it a benefit if people<br =
class=3D"">learned from the document, and discovered things that they =
had not heard<br class=3D"">of before.<br class=3D""><br class=3D"">There =
is no "insisting" of any kind.<br class=3D""><br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">[ &nbsp;Note 1: I think =
it is important to disclose that several of the<br class=3D"">items in =
this list appear to be more or less quoted out of my own<br =
class=3D"">blockstream-internal descriptions of things we've been =
working on in<br class=3D"">Bitcoin.<br class=3D"">A while back Adam =
Back asked me to publish something which contained<br =
class=3D"">significant chunks of this document more or less verbatim, =
<br class=3D""></blockquote>He probably showed you an earlier draft. But =
I wrote almost all of this<br class=3D"">myself, and I can only recall 2 =
or 3 phrases (not even complete<br class=3D"">sentences) included from =
Adam Back. And most of the phrases are<br class=3D"">themselves just =
boring descriptions that I'm sure anyone could write.<br class=3D"">Some =
phrases may have simply been taken from <a href=3D"http://bitcoincore.org"=
 class=3D"">bitcoincore.org</a> or<br class=3D"">somewhere similar.<br =
class=3D""><br class=3D"">I am not exactly sure what you are insinuating =
but I encourage you to<br class=3D"">clarify it.<br class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">and I<br =
class=3D"">declined saying that I personally disagree with some of his =
points and<br class=3D"">didn't think that Blockstream attempting to =
redirect the Bitcoin<br class=3D"">project (esp towards drivechains) was =
appropriate-- along with my<br class=3D"">(above) views on roadmaps =
(which I have included here a private email<br class=3D"">thread on the =
subject). I feel it's important to disclose this, and<br class=3D"">that =
the document was not otherwise created with the input of project<br =
class=3D"">contributors (except Luke-Jr, apparently). I wasn't =
previously aware<br class=3D"">that Adam had been working with Paul on =
this, had I been I would have<br class=3D"">also encouraged people to be =
a little more transparent about it. ]<br class=3D""></blockquote>I =
really don't understand what you are disclosing. That Adam asked you<br =
class=3D"">for feedback on the draft? And then, in the next sentence, =
that not<br class=3D"">enough experts were asked for feedback on the =
draft? I'm legitimately<br class=3D"">confused by this part.<br =
class=3D""><br class=3D"">As I stated, we can remove the drivechain =
section. But surely you can<br class=3D"">appreciate how bizarre your =
position on roadmaps is. What exactly, did<br class=3D"">you intended to =
create at [1]? Since it is described explicitly as "the<br =
class=3D"">roadmap in Capacity increases for the Bitcoin system", have =
you been<br class=3D"">disagreeing with it's characterization as a =
'roadmap' this entire time?<br class=3D"">One wonders why you haven't =
said anything until now.<br class=3D""><br class=3D"">[1] <a =
href=3D"https://bitcoincore.org/en/2015/12/21/capacity-increase/" =
class=3D"">https://bitcoincore.org/en/2015/12/21/capacity-increase/</a><br=
 class=3D""><br class=3D"">In my first email I list the benefits of =
having a roadmap. One benefit<br class=3D"">is that, without one, it is =
likely that a large majority of outsiders<br class=3D"">have almost no =
idea at all what is being worked on, what effect it will<br =
class=3D"">have, or when it might be ready, or to whom/what they should =
turn to for<br class=3D"">advice on such matters. Do you have a =
different way of addressing this<br class=3D"">communication problem?<br =
class=3D""><br class=3D"">Paul<br class=3D""><br =
class=3D"">_______________________________________________<br =
class=3D"">bitcoin-dev mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D""><a =
href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br class=3D""></div></div></blockquote></div><br =
class=3D""></div></div></body></html>=

--Apple-Mail=_08DB5B61-10CC-4F59-B819-AA7B5338478F--

--Apple-Mail=_469E18AE-6CAA-4425-AE12-DE90ECAF00FF
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJZZVQOAAoJEOxnICvpCVJHK1QQAMfW67/uCq058RJbdzhq964l
0HsWS5rZ2mP1nylv+AjJWM4Lj/gob+/At4X80e6kVuRPKvy3IpIspJ78goIMooti
zrAEk2+qBrx/b63Z0y7AuW1x+m1XR+GHVAliIOs6PQKkuMmS/RKmpgvxtJfdQNYS
RtEkDmt3rh/jpw9jsxa2JVDUzMHwm1KSJ47GkgSuIG3PaHVDbjCy7wHDECLTCPbs
oFtTk8jPdjkczy6BOJz2rl5atB94XsTjwUuRPp42zLqQ3c4ldZGfKweaJIF8bHZZ
HazBHLp8Z6a8hSOBTCrcHNebZxl4UnKVwvaH8Ezus5zAOnxCP4PYcEhZrg6eWhiN
Ei4Rtj7RZNuA1vmZ09LiZRZLFETMhJm6t+NYOHJuiyQ/RpqIFWWRbSIQE76NxSrw
JHmy/sw6sfGyWcCX/kAXM8tBWkBQUZomkRVjI3M/u2IX1HbaPi2iAKd/N8i2vWjf
7UU9o+8mYoizk+UiEzXAB4nZFpfwNvqKrR8KkGikqjixdRj8N73oKBGX8YbdLMIv
TlhKcyXdwCrbnZrP0UulViwI+RXq9xirCMYDaEEnVdM7gwBbU0NL12kl1XmQSOAA
mVpYasSpO089dks1qhuvby+eI0J+dxxiFZCrJm30l+uKNbZezNxI2Kjri6zw5kH1
/b91xvTewbtsr+ZfxHt0
=jUUL
-----END PGP SIGNATURE-----

--Apple-Mail=_469E18AE-6CAA-4425-AE12-DE90ECAF00FF--