To: bitcoin-dev@lists.linuxfoundation.org
References: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
From: Ross Nicoll <jrn@jrn.me.uk>
Message-ID: <55A9421B.6040605@jrn.me.uk>
Date: Fri, 17 Jul 2015 18:57:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101
	Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------050707030505060108020400"
Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
Precedence: list

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

I'd back this if we can't find a permanent solution - 2MB gives us a lot 
more wiggle room in the interim at least; one of my concerns with block 
size is 3 transactions per second is absolutely tiny, and we need space 
for the network to search for an equilibrium between volume and pricing 
without risk of an adoption spike rendering it essentially unusable.

I'd favour switching over by block height rather than time, and I'd 
suggest that given virtually every wallet/node out there will require 
testing (even if many do not currently enforce a limit and therefore do 
not need changing), 6 months should be considered a minimum target. I'd 
open with a suggestion of block 390k as a target.

Ross

On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:
> Opening a mailing list thread on this BIP:
>
> BIP PR: https://github.com/bitcoin/bips/pull/173
> Code PR: https://github.com/bitcoin/bitcoin/pull/6451
>
> The general intent of this BIP is as a minimum viable alternative plan 
> to my preferred proposal (BIP 100).
>
> If agreement is not reached on a more comprehensive solution, then 
> this solution is at least available and a known quantity.  A good 
> backup plan.
>
> Benefits:  conservative increase.  proves network can upgrade. 
>  permits some added growth, while the community & market gathers data 
> on how an increased block size impacts privacy, security, 
> centralization, transaction throughput and other metrics.  2MB seems 
> to be a Least Common Denominator on an increase.
>
> Costs:  requires a hard fork.  requires another hard fork down the road.
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--------------050707030505060108020400
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dwindows-1252"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    I'd back this if we can't find a permanent solution - 2MB gives us a
    lot more wiggle room in the interim at least; one of my concerns
    with block size is 3 transactions per second is absolutely tiny, and
    we need space for the network to search for an equilibrium between
    volume and pricing without risk of an adoption spike rendering it
    essentially unusable.<br>
    <br>
    I'd favour switching over by block height rather than time, and I'd
    suggest that given virtually every wallet/node out there will
    require testing (even if many do not currently enforce a limit and
    therefore do not need changing), 6 months should be considered a
    minimum target. I'd open with a suggestion of block 390k as a
    target.<br>
    <br>
    Ross<br>
    <br>
    <div class=3D"moz-cite-prefix">On 17/07/2015 16:55, Jeff Garzik via
      bitcoin-dev wrote:<br>
    </div>
    <blockquote
cite=3D"mid:CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmai=
l.com"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>Opening a mailing list thread on this BIP:</div>
        <div><br>
        </div>
        BIP PR:=A0<a moz-do-not-send=3D"true"
          href=3D"https://github.com/bitcoin/bips/pull/173">https://githu=
b.com/bitcoin/bips/pull/173</a>
        <div>Code PR:=A0<a moz-do-not-send=3D"true"
            href=3D"https://github.com/bitcoin/bitcoin/pull/6451">https:/=
/github.com/bitcoin/bitcoin/pull/6451</a></div>
        <div><br>
        </div>
        <div>The general intent of this BIP is as a minimum viable
          alternative plan to my preferred proposal (BIP 100).</div>
        <div><br>
        </div>
        <div>If agreement is not reached on a more comprehensive
          solution, then this solution is at least available and a known
          quantity.=A0 A good backup plan.</div>
        <div><br>
        </div>
        <div>Benefits: =A0conservative increase. =A0proves network can
          upgrade. =A0permits some added growth, while the community &amp=
;
          market gathers data on how an increased block size impacts
          privacy, security, centralization, transaction throughput and
          other metrics. =A02MB seems to be a Least Common Denominator on
          an increase.</div>
        <div><br>
        </div>
        <div>Costs: =A0requires a hard fork. =A0requires another hard for=
k
          down the road.</div>
        <div><br>
        </div>
        <div><br>
        </div>
      </div>
      <br>
      <fieldset class=3D"mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap=3D"">_______________________________________________
bitcoin-dev mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://lists.linuxfoundation.=
org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailm=
an/listinfo/bitcoin-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------050707030505060108020400--