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 741993EE for ; Tue, 11 Jul 2017 22:17:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f179.google.com (mail-qt0-f179.google.com [209.85.216.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 831C2FE for ; Tue, 11 Jul 2017 22:17:18 +0000 (UTC) Received: by mail-qt0-f179.google.com with SMTP id 32so5150711qtv.1 for ; Tue, 11 Jul 2017 15:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=rNAN+BDQEU5w66j6UFC5Epdo8eUZ2yBXAeCJKxZt3Ys=; b=FGN96ky0G7TN/js8mi6Cgb6kEhjqiw3nYTrpdTsDvx0iRWMfMz/I5HZEGaEL1eiVqq WyirctohMXtKuzbVyt0KTbk+i9r3MHOTcgf3HjtxqpiMuM0+QgneG+sWN+GSXu8zvTAq 2Qj3KZA55mJcQQENwwHUOMkCSFayg3YaAuUrdW1I29gZv9sS2/yHwH2mAtZL63iCPKFq quA2y5Dx/Zz4Juh3LTJw5SWiGjDyKW7LOqcqkHSpgdyRoy1JJaxnBERabEefSCgKU/xp /oIZq23iZJTstJLFCQ0AB31aTEZOpiisXsgt0RakcK9oPnAJE/IXhFqznriF2CTj5Id6 WLjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=rNAN+BDQEU5w66j6UFC5Epdo8eUZ2yBXAeCJKxZt3Ys=; b=T120j/OPJ9Tvj+1cmEt3Br3rQNpSoQImOGN9U7y1kS5P2vUkugotXRcRI+aMjVAVI9 ctClAmgNmlEcOz4CFcUIBT5ZvzORo40DvcQbR+wIz6Vg2AkgTujNHNe+ws3tSHQNk4GM RFb22GDaV1/QWimQbgZ16m8PKlM/SX5JwvutAa6WDAXxh4/xlK76As+MTQoTtdnGuCMs DLr7YkiLuuF5xpgd5I51IgUgNC/qrJB4wTuwWR+lxhaOgCWKLdbhZUHeU4Ic+2zCGVkR o83lbnCl4R7tn1uUSVLK892EufKnYO0lFdb9E88zQ1uprnWU8mnjtvr+MC5ZCXE4Z5/E NwaQ== X-Gm-Message-State: AIVw113CdLHN0HsEm40NrnUU90QgGp+BSkXFXK1P/y3pC4BJD13F98Ce nx4cpOta5yOKmFwV X-Received: by 10.237.47.39 with SMTP id l36mr2813233qtd.181.1499811437212; Tue, 11 Jul 2017 15:17:17 -0700 (PDT) Received: from [192.168.1.104] (ool-45726efb.dyn.optonline.net. [69.114.110.251]) by smtp.googlemail.com with ESMTPSA id d14sm433600qtc.58.2017.07.11.15.17.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 15:17:15 -0700 (PDT) To: Gregory Maxwell , Bitcoin Protocol Discussion References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com> From: Paul Sztorc Message-ID: <1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com> Date: Tue, 11 Jul 2017 18:17:19 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 X-Mailman-Approved-At: Tue, 11 Jul 2017 22:29:43 +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:17:19 -0000 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=20 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 wa= s > 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 publishe= d > 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 mar= s. 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 insec= ure, > patent encumbered, or practically useless... (It won't be but no one co= uld > tell that from your post; because it doesn't even exist as a concrete p= roposal) 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-- e= specially > 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,=20 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