path: root/b6/34ff86bd548d5d05056330c315e684397559f3

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--