To: Chris Stewart <chris@suredbits.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
	<CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <f79b9693-b8a5-c496-9dd9-d74704855d0e@gmail.com>
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: <CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------96CC1F207186514D125BC366"
Content-Language: en-US
Subject: Re: [bitcoin-dev] Updating the Scaling Roadmap
Precedence: list

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
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> 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

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi Chris,<br>
      <br>
      On 7/11/2017 12:03 PM, Chris Stewart wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com">
      <div dir="ltr">
        <div>
          <div>
            <div>Concept ACK.<br>
              <br>
            </div>
            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! :-)<br>
          </div>
        </div>
      </div>
    </blockquote>
    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).<br>
    <br>
    <blockquote type="cite"
cite="mid:CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com">
      <div dir="ltr">
        <div>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? <br>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    Paul<br>
    <br>
    <blockquote type="cite"
cite="mid:CAGL6+mHQZ3UP10msk65OO+Uk0hn7j+dkmJap_M7FgWfSZaYYJQ@mail.gmail.com">
      <div dir="ltr">
        <div><br>
        </div>
        -Chris<br>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Mon, Jul 10, 2017 at 11:50 AM, Paul
          Sztorc via bitcoin-dev <span dir="ltr">&lt;<a
              href="mailto:bitcoin-dev@lists.linuxfoundation.org"
              target="_blank" moz-do-not-send="true">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
            Summary<br>
            =========<br>
            <br>
            In my opinion, Greg Maxwell's scaling roadmap [1] succeeded
            in a few<br>
            crucial ways. One success was that it synchronized the
            entire Bitcoin<br>
            community, helping to bring finality to the (endless)
            conversations of<br>
            that time, and get everyone back to work. However, I feel
            that the Dec<br>
            7, 2015 roadmap is simply too old to serve this function any
            longer. We<br>
            should revise it: remove what has been accomplished,
            introduce new<br>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>

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