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 09EDD4A6 for ; Wed, 12 Jul 2017 00:07:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f177.google.com (mail-ua0-f177.google.com [209.85.217.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 466013D2 for ; Wed, 12 Jul 2017 00:07:54 +0000 (UTC) Received: by mail-ua0-f177.google.com with SMTP id z22so4956990uah.1 for ; Tue, 11 Jul 2017 17:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AWzFqfKlYKo/mR1N6SS0qfTZBYU3uTD1/rVl6ZyB0DE=; b=vh2lZFfHF/SNGvtNQkMcDH7wrDK544WxhMcJlK+lDPbeodKnmSGcyKA09nnuvIraqr ODSvEeHjPl7dlCvnLntU7p8wnmGrSXA2qoL3GbSImI53NU/MyYBguJw0VO/TEXHvhQgj Qe6EBMp4g+O8v/uHXPfB/g2TrjBew93Yjb/vY0ms+IvJ384+VwOLUBSGwxlmr5ZsjsS4 nBT2TU1ApYldbL8rB68vFe4NtXKae4p20+oSlEwtQRATEL+JTRMhSGj/I7j99lPtd18t O8cUVCy2YLHwP54l9RBIwW5cSKsrpiFdEvDJPiCnpqtjBhVV4V7iq96mDYe+ceLQ33Lz eb+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AWzFqfKlYKo/mR1N6SS0qfTZBYU3uTD1/rVl6ZyB0DE=; b=kIpruAK8EgiYydXdoBiHDQGOO3cw31sWa7jy+lRHNGYSCKCOG9AtExx1spPw775bO0 uQ5o9FiPRl294VsqQMFWTZi9cA5I0ClvxJxSRbRiC3HLb7p1k9J0m6bdF6pvM/Tijhit 9J18peAv/zeduJn8c4SFi78qYKEa6ePQkRBa5PoQ7s2nfv+Q38uhmeQq0vcDpFALuJqN Ua3braybR/BQFKSjxzHw8O6ysMAebSLGpwGOERFACcF1mrwWZHPmhbE/2P19qzEEnJc/ icF6N/7wXllL0OIRosGA0JArJED+HCOAo8iA9RZ4b8FaOaA5zkTiBok0iXTm+rGUh+oJ COZQ== X-Gm-Message-State: AIVw1138CHD693J8WOBaoI6k9btp9QQqoYJYLwwT0r/5x6gSPp1Mfu/q G8VcY49elPExwJZBJinXAW2Gu4NRQQ== X-Received: by 10.176.81.70 with SMTP id f6mr1653889uaa.41.1499818073299; Tue, 11 Jul 2017 17:07:53 -0700 (PDT) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.90.21 with HTTP; Tue, 11 Jul 2017 17:07:51 -0700 (PDT) In-Reply-To: <1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com> References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com> <1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com> From: Gregory Maxwell Date: Wed, 12 Jul 2017 00:07:51 +0000 X-Google-Sender-Auth: 40pOy50rEXtpwBnEeRFOxfTDD0o Message-ID: To: Paul Sztorc Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 12 Jul 2017 00:13:14 +0000 Cc: Bitcoin Protocol Discussion 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: Wed, 12 Jul 2017 00:07:55 -0000 On Tue, Jul 11, 2017 at 10:17 PM, Paul Sztorc wrote: > I don't understand this at all. This document attempts to do exactly > what its predecessor did -- nothing more or less. That might be your impression, then you've misunderstood what I intended-- What I wrote was carefully constructed as a personal view of how things might work out. It never claimed to be a a project roadmap. Though as usual, I work hard to propose things that I believe will be successful... and people are free to adopt what they want. And to the extent that it got taken that way I think it was an error and that it has harmed progress in our community; and created more confusion about control vs collaboration. With perfect hindsight I wouldn't have posted it; especially since we've learned that the demand for increased capacity from many people was potentially less than completely earnest. (The whole, can't double capacity until we quadruple it thing...) > 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 don't agree that you have; but for the purpose of this thread doesn't really matter if I (specifically) do or don't agree. It's an objective truth that many people do not yet believe these concerns have been addressed. > 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 That Adam asked me to write publish a new "roadmap" for Bitcoin as you've done here, with particular features and descriptions, which I declined; and explained why I didn't believe that was the right approach. And Adam worked with you on the document, and provided content for it (which I then recognized in the post). Set aside what you know to be true for a moment and consider how this might look to an outsider who found out about it. It could look a like Blockstream was trying to influence the direction of Bitcoin by laundering proposals through an apparently unaffiliated third party. Doubly so considering who participated in your drafting and who didn't (more below). I don't think in actuality you did anything remotely improper (ill-advised, perhaps, since your goal to speak for developers but you didn't speak to them, IMO--) but I think transparency is essential to avoid any appearance of misconduct. > 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. I did-- As Bryan pointed out... with the exception of the intro and end and a couple sentences in the middle my entire response to your post, with the position on "roadmaps" was written a long time ago, specifically to complain about and argue against that particular approach. > 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? I think you may be mistaking a roadmap with "communications"-- people taking about research they are exploring is great! and we should have more of it. But like with RedHat and kernel features, we can't really roadmap things that are unresourced and currently just unimplemented exploration or test code-- without seeing things which are more or less done the community can't rightfully decide if they'd want to support something or not. Perhaps they'll be good things perhaps awful-- the devil is in the details, and until an effort is fairly mature, you cannot see the details. There have, for example, been signature aggregation proposals in the past that required address reuse (could only aggregate if they're reused). I would strongly oppose such a proposal, and I hope everyone else here would too. So if I were a third party looking at your message, rather than the person who initially proposed the agg sig thing you're talking about, I wouldn't know if I could love it or hate it yet; and probably couldn't be expected to have much of an opinion on it until there is a BIP and/or example implementation. To the extent that a roadmap differs from communications in general, it is in that it also implies things that none of us can promise except for our own efforts; Completion of implementations, success of experiments, adoption-- basically assuming a level of top down control that doesn't exist in a wide public collaboration. One of the great challenges in our industry is that we don't have rings of communication: We don't have much in the way of semi-experts to communicate to semi-semi-experts to communicate to media pundits to communicate to the unwashed masses-- at each level closing the inferential gap and explaining things in terms the audience understands. We don't have things like LWN. We'll get there, but it it took the Linux world decades to build to what it has now. I think various forces in the industry work against us-- e.g. we lose a mot of mid tier technical people to the allure of striking it rich printing money in their own altcoins. It might be attractive to try to end-run the slow development appropriate web of reliable communications by deploying high authority edicts, but it ultimately can't work because it doesn't map to how things are accomplished, not in true collaborative open source, and certainly not in an effort whos value comes substantially from decentralization. Doing so, I fear, creates a false understanding of authority. (It's a common misunderstanding, for example, that people do what I want (for example); but in reality, I just try to avoid wasting my time advocating things that I don't think other people are already going to do; :) otherwise, if _I_ want something done I've got to do it myself or horse trade for it, just like anyone else.) One of the great things about general communications is anyone can do it. Of course, unless they're talking about their own work, they can't promise any of it will be completely-- but that is always true. If someone wants some guarantee about work, they have to be willing to get it done themselves (and, of course, if it's a consensus feature-- that much is necessary, but still not sufficient to get a guarantee). [from your other reply] >> A fine intention, but I've checked with many of the top contributors >> and it sounds like the only regular developer you spoke with was >> Luke-Jr. Next time you seek to represent someone you might want to >> try talking to them! > > That is false. I could provide a list of names but I'm really not sure > what would be gained as result. You yourself admit that it is an > excellent list of research, almost all which you support directly. > > So I think your only real objection is that I didn't talk to you > specifically. Come now, this is needlessly insulting. I would have made the same comment if you had talked to me because you didn't talk to most/all of Matt Corallo, Wladimir, Pieter Wuille, Alex Morcos, etc.... e.g. the people doing most of the work of actually building the system. Before making that comment I went and checked with people to find out if only I was left out. Talking to Adam (who isn't involved in the project) and Luke-jr (who is but is well known for frustratingly extreme minority positions and also contracts for Blockstream sometimes) isn't a great approach for the stated goal of speaking for developers!