From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id ED4E7ABB for ; 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 ; 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 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: References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com> <1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com> To: Paul Sztorc , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = -- 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 = > 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 = 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/ = >=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 = > 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 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-Ju= ne/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> wrote:

Hi = Greg,


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.

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.

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.


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.

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.

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.

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.


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.

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.

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.

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.


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.

There = is no "insisting" of any kind.


[  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 or
somewhere similar.

I am not exactly sure what you are insinuating = but I encourage you to
clarify it.

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.

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.

[1] https://bitcoincore.org/en/2015/12/21/capacity-increase/
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?

Paul

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>

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