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 F3CB8BCF for ; Tue, 11 Jul 2017 20:18:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f172.google.com (mail-qt0-f172.google.com [209.85.216.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0338716D for ; Tue, 11 Jul 2017 20:18:03 +0000 (UTC) Received: by mail-qt0-f172.google.com with SMTP id b40so2839081qtb.2 for ; Tue, 11 Jul 2017 13:18:03 -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-language; bh=HeLWqGS8n51Vk4N+nJKPVgfSGMejNbrm5H3Ib7IAaG8=; b=AMEQ3JuouZPiItx0Cj1vzp/ED702G8xSdz3bUNZxNs352oq88Z/usGPAC68+K4UIHq 1CSP5aOcDX+Ec7qOEpkzkltLusi9p++XmQBVuCDEkjX0CDFymqjOOLRIY6s4f3eIWrKQ 7zgGGeZhhemmuI3/Ss9Z9DVl+nCqqYzj/Lx1QfBoN+g/Yc9hwB/oZF84sMGtYpBZPNT8 WZ5zSj0Yf1yFhrFscgjpx0Z6yy2b/jz+eL/JVauH+4zaWZR3b7vvCOM/eKi7sNoJ6Zjq iCapaqwGa9CGHl39szvgJylXAVpkSK10c5rdlBbX0o/DsRpyQ37+ig74NInoW7jRSQne ISUg== 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-language; bh=HeLWqGS8n51Vk4N+nJKPVgfSGMejNbrm5H3Ib7IAaG8=; b=K2YdR+7Rbc7rq065rVqhDeCp0hs+gX2DA6mIM5PvDQkZv3+tbMdI7VoSSUjBbui2lc Qjy9i2AqilHNlCxNyLFqol2+Hbf2J0rmav3TnFm1pZBve+YGgqXjZEB3Ne7mX3lUFxCy r7/a+n5s5Gf1PTTarbTJmSWnp2cESGNwiW00lrlPfBch6TY3PZx1rCna/zx3wVtvRl7l Lq3E+00hDtblMIkNTKafFnM9XOv2elhNFpLf3Q5i5qbUIpc2YYz0f/uSfkN8vFiDvJUb 2OD5Fz+Nkm495TnwthUyQOKy8PFVqjQEmTE/Ggwyvogiqyv4SJMFbe6mSaEusBs8q177 xTow== X-Gm-Message-State: AIVw113w8/Shnj4BK1dQH/VzqINdUCCKtL0QICiyHrbCdXfEge3mNsJ0 Cnr0zgPiRhJXe85x X-Received: by 10.200.54.38 with SMTP id m35mr2186475qtb.220.1499804282974; Tue, 11 Jul 2017 13:18:02 -0700 (PDT) Received: from [192.168.1.104] (ool-45726efb.dyn.optonline.net. [69.114.110.251]) by smtp.googlemail.com with ESMTPSA id r33sm237477qtc.43.2017.07.11.13.18.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jul 2017 13:18:01 -0700 (PDT) To: Chris Stewart , Bitcoin Protocol Discussion References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com> From: Paul Sztorc Message-ID: Date: Tue, 11 Jul 2017 16:18:04 -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: multipart/alternative; boundary="------------96CC1F207186514D125BC366" Content-Language: en-US X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 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: Tue, 11 Jul 2017 21:09:27 +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 20:18:05 -0000 This is a multi-part message in MIME format. --------------96CC1F207186514D125BC366 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Chris, On 7/11/2017 12:03 PM, Chris Stewart wrote: > Concept ACK. > > I think you are overstating the readiness of drivechains though. I > think the optimistic estimate for drivechains to be ready for bitcoin > core is a year out from today. More likely the date should be early > 2018. Still a lot of work to be done! :-) It depends on interest, I think. What remains to be done is more easily parallelized, and in some cases (eg smartphone wallets) there are incentives for private individuals and businesses to hustle their part out (merely for reasons of competitiveness). > Also I don't know if I would put a hard fork suggestion in the scaling > map. If drivechains are successful they should be viewed as the way we > scale -- not hard forking the protocol. Do you still have capacity > concerns if drivechains are successful? I wrote the roadmap to try to be representative of a Core / developer position. I am philosophically against hard forks, but HFs were in the end of the previous roadmap so I felt it should stay. And, I felt that if I decided to unilaterally remove it, it would be perceived as excessive campaigning for Drivechain. And I also felt that to remove it, when so many industry members recently put their weight behind a fast hard fork, would be perceived as a reaction to that attempt, and would then overwhelm the document with political polarization, for really no benefit. Paul > > -Chris > > On Mon, Jul 10, 2017 at 11:50 AM, Paul Sztorc via bitcoin-dev > > wrote: > > > Summary > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a fe= w > crucial ways. One success was that it synchronized the entire Bitco= in > community, helping to bring finality to the (endless) conversations= of > that time, and get everyone back to work. However, I feel that the = Dec > 7, 2015 roadmap is simply too old to serve this function any > longer. We > should revise it: remove what has been accomplished, introduce new > --------------96CC1F207186514D125BC366 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Chris,

On 7/11/2017 12:03 PM, Chris Stewart wrote:
Concept ACK.

I think you are overstating the readiness of drivechains though. I think the optimistic estimate for drivechains to be ready for bitcoin core is a year out from today. More likely the date should be early 2018. Still a lot of work to be done! :-)
It depends on interest, I think. What remains to be done is more easily parallelized, and in some cases (eg smartphone wallets) there are incentives for private individuals and businesses to hustle their part out (merely for reasons of competitiveness).

Also I don't know if I would put a hard fork suggestion in the scaling map. If drivechains are successful they should be viewed as the way we scale -- not hard forking the protocol. Do you still have capacity concerns if drivechains are successful?

I wrote the roadmap to try to be representative of a Core / developer position. I am philosophically against hard forks, but HFs were in the end of the previous roadmap so I felt it should stay. And, I felt that if I decided to unilaterally remove it, it would be perceived as excessive campaigning for Drivechain. And I also felt that to remove it, when so many industry members recently put their weight behind a fast hard fork, would be perceived as a reaction to that attempt, and would then overwhelm the document with political polarization, for really no benefit.

Paul


-Chris

On Mon, Jul 10, 2017 at 11:50 AM, Paul Sztorc via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Summary
=========

In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
crucial ways. One success was that it synchronized the entire Bitcoin
community, helping to bring finality to the (endless) conversations of
that time, and get everyone back to work. However, I feel that the Dec
7, 2015 roadmap is simply too old to serve this function any longer. We
should revise it: remove what has been accomplished, introduce new


--------------96CC1F207186514D125BC366--