MIME-Version: 1.0
In-Reply-To: <1EF70EBC-8BB8-4A93-8591-52B2B0335F6C@petertodd.org>
References: <CALgxB7udA85BWetBGc-RN=72ZtVPK9Q5HW8YRDKA08M38XqJqQ@mail.gmail.com>
	<1EF70EBC-8BB8-4A93-8591-52B2B0335F6C@petertodd.org>
Date: Sat, 27 Jun 2015 12:19:04 -0400
Message-ID: <CALgxB7usetoaNCObhG36TrdYgKuP4TSPPNkGatvim1oWUMxaeQ@mail.gmail.com>
From: Michael Naber <mickeybob@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=bcaec54fb2c422672e0519823720
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
Precedence: list

--bcaec54fb2c422672e0519823720
Content-Type: text/plain; charset=UTF-8

That test seems like a reasonable suggestion; 840GB is not prohibitive
given today's computing costs. What other than the successful result of
that test would you want to see before agreeing to increase the block size
to 8MB?


On Sat, Jun 27, 2015 at 11:21 AM, Peter Todd <pete@petertodd.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>
> On 27 June 2015 10:39:51 GMT-04:00, Michael Naber <mickeybob@gmail.com>
> wrote:
> >Compromise: Can we agree that raising the block size to a static 8MB
> >now
> >with a plan to increase it further should demand necessitate except in
> >the
> >special case above is a reasonable path forward?
>
> It's not a reasonable path forward right now given the lack of testing
> done with 8MB+ blocks, among many other problems. A way to help make that
> appear more reasonable would be to setup a 8MB testnet as I suggested, with
> two years or so of 8MB blocks in history as well as a large UTXO set to
> test performance characteristics.
>
> Of course, that'll be a 840GB download - if that's unreasonable you might
> want to ask why 8MB blocks are reasonable...
> -----BEGIN PGP SIGNATURE-----
>
> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVjr9n
> AAoJEMCF8hzn9Lnc47AIAIIwu4maaJs4pAKpK00jQnhPNIQ8LPvijD/8vvyugA1z
> OLxlRrn8zs7JPFbxWOAzK2qzT1RksSd0gbXqWm/Saqk9CAG5LBp7Oq0HAVE23XYt
> 6BvyhjyhYaZjDrv+SZvlSjdl5xfpDNPMIXMi7XblKD9hm1GIUSVIYAOinOSVIy0B
> HlKyn/xc4MaO8DuzQcs0vsNMudVQFLMOLjMWz/7iv41NnB/Ujjzv/6845Z1g7Opf
> d5AfxhPHZixshqav/lF7ly7xQwSZZpoJCyFdtzCNG47EQmFYY9e22uy1KVzS7Zeo
> qYPi3KRx5+vFtHHJMDYG5EIMTwI4l/4+lY/Sd0CFWss=
> =0IOS
> -----END PGP SIGNATURE-----
>
>

--bcaec54fb2c422672e0519823720
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>That test seems like a reasonable suggestion; 840GB i=
s not prohibitive given today&#39;s computing costs. What other than the su=
ccessful result of that test would you want to see before agreeing to incre=
ase the block size to 8MB?</div><br><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">On Sat, Jun 27, 2015 at 11:21 AM, Peter Todd <span dir=
=3D"ltr">&lt;<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@p=
etertodd.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex">-----BEGIN PGP SIGNE=
D MESSAGE-----<br>
Hash: SHA256<br>
<span class=3D""><br>
<br>
<br>
On 27 June 2015 10:39:51 GMT-04:00, Michael Naber &lt;<a href=3D"mailto:mic=
keybob@gmail.com">mickeybob@gmail.com</a>&gt; wrote:<br>
&gt;Compromise: Can we agree that raising the block size to a static 8MB<br=
>
&gt;now<br>
&gt;with a plan to increase it further should demand necessitate except in<=
br>
&gt;the<br>
&gt;special case above is a reasonable path forward?<br>
<br>
</span>It&#39;s not a reasonable path forward right now given the lack of t=
esting done with 8MB+ blocks, among many other problems. A way to help make=
 that appear more reasonable would be to setup a 8MB testnet as I suggested=
, with two years or so of 8MB blocks in history as well as a large UTXO set=
 to test performance characteristics.<br>
<br>
Of course, that&#39;ll be a 840GB download - if that&#39;s unreasonable you=
 might want to ask why 8MB blocks are reasonable...<br>
-----BEGIN PGP SIGNATURE-----<br>
<br>
iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVjr9n<br>
AAoJEMCF8hzn9Lnc47AIAIIwu4maaJs4pAKpK00jQnhPNIQ8LPvijD/8vvyugA1z<br>
OLxlRrn8zs7JPFbxWOAzK2qzT1RksSd0gbXqWm/Saqk9CAG5LBp7Oq0HAVE23XYt<br>
6BvyhjyhYaZjDrv+SZvlSjdl5xfpDNPMIXMi7XblKD9hm1GIUSVIYAOinOSVIy0B<br>
HlKyn/xc4MaO8DuzQcs0vsNMudVQFLMOLjMWz/7iv41NnB/Ujjzv/6845Z1g7Opf<br>
d5AfxhPHZixshqav/lF7ly7xQwSZZpoJCyFdtzCNG47EQmFYY9e22uy1KVzS7Zeo<br>
qYPi3KRx5+vFtHHJMDYG5EIMTwI4l/4+lY/Sd0CFWss=3D<br>
=3D0IOS<br>
-----END PGP SIGNATURE-----<br>
<br>
</blockquote></div><br></div></div>

--bcaec54fb2c422672e0519823720--