MIME-Version: 1.0
In-Reply-To: <CABsx9T2wsc=+seaWs=v5d_kPpC4u-xTnsjuPMO7PYhQN+0-KAQ@mail.gmail.com>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
	<20150623192838.GG30235@muck>
	<CABsx9T2wsc=+seaWs=v5d_kPpC4u-xTnsjuPMO7PYhQN+0-KAQ@mail.gmail.com>
Date: Tue, 23 Jun 2015 22:26:38 +0200
Message-ID: <CAPg+sBj0Zk-k7fjams1YWFESDYHHp+r=NeFQAnVgghppNKDGxg@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=f46d0444ec5b23f49a05193535e2
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Precedence: list

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

On Tue, Jun 23, 2015 at 10:12 PM, Gavin Andresen <gavinandresen@gmail.com>
wrote:

> On Tue, Jun 23, 2015 at 3:28 PM, Peter Todd <pete@petertodd.org> wrote:
>
>> Wladimir noted that 'The original presented intention of block size
>> increase was a one-time "scaling" to grant time for more decentralizing
>> solutions to develop'
>>
>> Comments?
>>
>
> Consensus is that this process is too painful to go through once a year.
> I agree.
>

If you believe we will need to go through this process once a year, we are
not talking about a one-time scaling to grant time for more decentralizing
solutions. It means you think we should keep scaling. I don't disagree
there - as long as we're talking about scaling as availability of
bandwidth, storage and processing power increase, there is no reason
Bitcoin's blockchain can't grow proportionally.

However, an initial bump 8 MB and the growth rate afterwards seem more like
a no-effectively-limit-ever to me.

I fear that the wish of not wanting to deal with - admittedly - a very hard
problem, resulted here in throwing away several protections we currently
have. And yes, I know you believe 8 MB won't be created immediately. I
truly, honestly, do not think so either. But I prefer a system where I
don't need to rely on anyone's guesses for the future.

-- 
Pieter

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

<div dir=3D"ltr">On Tue, Jun 23, 2015 at 10:12 PM, Gavin Andresen <span dir=
=3D"ltr">&lt;<a href=3D"mailto:gavinandresen@gmail.com" target=3D"_blank">g=
avinandresen@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On T=
ue, Jun 23, 2015 at 3:28 PM, Peter Todd <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">Wladimir noted that &#39;The original presente=
d intention of block size<br>
increase was a one-time &quot;scaling&quot; to grant time for more decentra=
lizing<br>
solutions to develop&#39;<br>
<br>
Comments?<br></blockquote><div><br></div></span><div>Consensus is that this=
 process is too painful to go through once a year.=C2=A0 I agree.<br></div>=
</div></div></div></blockquote><div><br></div><div>If you believe we will n=
eed to go through this process once a year, we are not talking about a one-=
time scaling to grant time for more decentralizing solutions. It means you =
think we should keep scaling. I don&#39;t disagree there - as long as we&#3=
9;re talking about scaling as availability of bandwidth, storage and proces=
sing power increase, there is no reason Bitcoin&#39;s blockchain can&#39;t =
grow proportionally.<br><br></div><div>However, an initial bump 8 MB and th=
e growth rate afterwards seem more like a no-effectively-limit-ever to me.<=
br><br></div><div>I fear that the wish of not wanting to deal with - admitt=
edly - a very hard problem, resulted here in throwing away several protecti=
ons we currently have. And yes, I know you believe 8 MB won&#39;t be create=
d immediately. I truly, honestly, do not think so either. But I prefer a sy=
stem where I don&#39;t need to rely on anyone&#39;s guesses for the future.=
<br><br>-- <br></div><div>Pieter<br><br></div></div><br></div></div>

--f46d0444ec5b23f49a05193535e2--