Message-ID: <554BAD3B.2050404@jrn.me.uk>
Date: Thu, 07 May 2015 19:21:47 +0100
From: Ross Nicoll <jrn@jrn.me.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
References: <554A91BE.6060105@bluematt.me>	<CANEZrP3wGWHdz+ut6pvke5TJJsc1rTFt8sn2KziX35oL5LAsyg@mail.gmail.com>	<CABm2gDpDvk2VsQ+mJ-BoeBKmvu9jBXNujZEFKuCStRNjFL6VOA@mail.gmail.com>	<CANEZrP2zAGCCBhNa4=9yw+A_Dn5o4SQXoPTE_qcJzZ1dFuF2tw@mail.gmail.com>	<CABm2gDqd6iHRUDKZWWTudcC1QkYa+rCuHjz7pMC2K1Db8wpgfA@mail.gmail.com>	<CANEZrP1CU0kB0vXeXUX1L8byaT-Zf2xg+3N+GeNthi_i6bn1qw@mail.gmail.com>	<CABsx9T2Nxvr4fqREMw3_LXftzsxrUAR1+9sVMa8_EpTnH1nN1Q@mail.gmail.com>	<554BA032.4040405@bluematt.me>	<CANEZrP3yM9wsSPNgpOsXDk-DjUy5PW2XuRTvK2AyCNbVJ5hZHw@mail.gmail.com>	<CADJgMzti7ROH90APiwg4NOAT5+Av=4i295b8VN0sbSLr4+WWRw@mail.gmail.com>
	<CANEZrP39jWHLF02z-81Z4+9X1vH5+hMuS=-3ED81=Q1o9U=DKw@mail.gmail.com>
In-Reply-To: <CANEZrP39jWHLF02z-81Z4+9X1vH5+hMuS=-3ED81=Q1o9U=DKw@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------030508090401080706080902"
Subject: Re: [Bitcoin-development] Block Size Increase
Precedence: list

This is a multi-part message in MIME format.
--------------030508090401080706080902
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Can I just add my own support for this - as has been stated elsewhere in 
this discussion, hard forks are difficult, and risky. The earlier we 
have a decision, and the earlier the change goes into the code, the 
easier that is.

Even if the decision was the actual block size change is fine to leave 
until 2020, I'd like to see the code committed ASAP so that every new 
install, and every upgrade from there on gets the new version.

My personal opinion only is that 7 transactions a second is insanely 
limited even if the main chain does nothing but act as a backbone 
between other chains and transaction networks. I don't think that's 
overly controversial. I think 2016 is too early for a 20mb block size, 
though. I'm inclined to suggest a schedule of expansion, say to 2mb in 
2016, 4mb in 2018, 8mb in 2020 and 20mb in 2022 where it stops. The 
intent would be to provide enough size pressure to motivate scaling 
work, while not limiting Bitcoin overly.

Further, I think this highlights that we need more work on fees. Right 
now fees and transactions included are fairly naive, but I'd like to see 
the absolute block size limit as a hard upper bound, with miners 
imposing soft limits based on a balance cost of storage, number of 
outputs vs inputs (and therefore impact on the UTXOs), and risk of 
orphan blocks to determine which transactions are actually worth 
including in each block. If anyone has numbers on block size vs orphan 
rate that would be really useful, BTW.

Ross

On 07/05/2015 19:06, Mike Hearn wrote:
>
>     I think you are rubbing against your own presupposition that
>     people must find and alternative right now. Quite a lot here do
>     not believe there is any urgency, nor that there is an immanent
>     problem that has to be solved before the sky falls in.
>
>
> I have explained why I believe there is some urgency, whereby "some 
> urgency" I mean, assuming it takes months to implement, merge, test, 
> release and for people to upgrade.
>
> But if it makes you happy, imagine that this discussion happens all 
> over again next year and I ask the same question.
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--------------030508090401080706080902
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Can I just add my own support for this - as has been stated
    elsewhere in this discussion, hard forks are difficult, and risky.
    The earlier we have a decision, and the earlier the change goes into
    the code, the easier that is.<br>
    <br>
    Even if the decision was the actual block size change is fine to
    leave until 2020, I'd like to see the code committed ASAP so that
    every new install, and every upgrade from there on gets the new
    version.<br>
    <br>
    My personal opinion only is that 7 transactions a second is insanely
    limited even if the main chain does nothing but act as a backbone
    between other chains and transaction networks. I don't think that's
    overly controversial. I think 2016 is too early for a 20mb block
    size, though. I'm inclined to suggest a schedule of expansion, say
    to 2mb in 2016, 4mb in 2018, 8mb in 2020 and 20mb in 2022 where it
    stops. The intent would be to provide enough size pressure to
    motivate scaling work, while not limiting Bitcoin overly.<br>
    <br>
    Further, I think this highlights that we need more work on fees.
    Right now fees and transactions included are fairly naive, but I'd
    like to see the absolute block size limit as a hard upper bound,
    with miners imposing soft limits based on a balance cost of storage,
    number of outputs vs inputs (and therefore impact on the UTXOs), and
    risk of orphan blocks to determine which transactions are actually
    worth including in each block. If anyone has numbers on block size
    vs orphan rate that would be really useful, BTW.<br>
    <br>
    Ross<br>
    <br>
    <div class="moz-cite-prefix">On 07/05/2015 19:06, Mike Hearn wrote:<br>
    </div>
    <blockquote
cite="mid:CANEZrP39jWHLF02z-81Z4+9X1vH5+hMuS=-3ED81=Q1o9U=DKw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir="ltr">
                <div class="gmail_extra">
                  <div class="gmail_quote">
                    <div>I think you are rubbing against your own
                      presupposition that people must find and
                      alternative right now. Quite a lot here do not
                      believe there is any urgency, nor that there is an
                      immanent problem that has to be solved before the
                      sky falls in.</div>
                  </div>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>I have explained why I believe there is some urgency,
              whereby "some urgency" I mean, assuming it takes months to
              implement, merge, test, release and for people to upgrade.</div>
            <div><br>
            </div>
            <div>But if it makes you happy, imagine that this discussion
              happens all over again next year and I ask the same
              question.</div>
          </div>
          <br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
<a class="moz-txt-link-freetext" href="http://ad.doubleclick.net/ddm/clk/290420510;117567292;y">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a></pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------030508090401080706080902--