MIME-Version: 1.0
In-Reply-To: <20150721135846.GB13429@savin.petertodd.org>
References: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
	<55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk>
	<CABm2gDr6qXzvcpX_To39kCEsnQNTQS4M5Y40Yk_Lw481rjvSag@mail.gmail.com>
	<20150721130412.GA4551@savin.petertodd.org>
	<20150721135846.GB13429@savin.petertodd.org>
Date: Wed, 22 Jul 2015 10:43:19 -0700
Message-ID: <CADm_WcZDLfAwCJn8qc1Myp-OQhgPzx+A7b6nw8u9Z7mgQ6hveg@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e0122aa626ed54e051b7a4eb9
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
Precedence: list

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

On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I don't agree with you at all.
>
> This is a case where if Jeff doesn't understand that issue, he's
> proposing changes that he's not competent enough to understand, and it'd
> save us a lot of review effort if he left that discussion. Equally, Jeff
> is in a position in the dev community where he should be that competent;
> if he actually isn't it does a lot of good for the broader community to
> change that opinion.
>
> I personally *don't* think he's doing that, rather I believe he knows
> full well it's a bad patch and is proposing it because he wants to push
> discussion towards a solution. Often trolling the a audience with bad
> patches is an effective way to motivate people to respond by writing
> better ones; Jeff has told me he often does exactly that.
>
>
mmmm kay.  Let's try to keep it technical, please.

2MB is a limit that has been discussed as a viable next-step, meeting with
the most consensus.

2MB gets beyond the 1MB hard fork issue, while still remaining within a
safety cap that should ensure the system does not go "off the rails" as
some has predicted.

Security, privacy and centralization are not going to disappear at 2MB.

Further, a limited step gains valuable field data for judging whether
further steps are warranted - thus informing the "better block size
solution" development process.

Finally, as stated in the initial PR, it is intended as a viable fallback
should we reach a point of criticality where the user community feels a
block size increase is warranted, yet cannot reach consensus on a fancy,
all-consuming solution be it 20MB, flexcap, BIP 100, BIP 102, etc.

I am open to suggestions for improving BIP 102.  The goal is a minimum
complexity fallback that others have previously agreed was a useful
kick-the-can compromise - a static 2MB cap.

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

<div dir=3D"ltr">On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-de=
v <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation=
.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span=
> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">I don&#39;t agree with you at all.<br>
<br>
This is a case where if Jeff doesn&#39;t understand that issue, he&#39;s<br=
>
proposing changes that he&#39;s not competent enough to understand, and it&=
#39;d<br>
save us a lot of review effort if he left that discussion. Equally, Jeff<br=
>
is in a position in the dev community where he should be that competent;<br=
>
if he actually isn&#39;t it does a lot of good for the broader community to=
<br>
change that opinion.<br>
<br>
I personally *don&#39;t* think he&#39;s doing that, rather I believe he kno=
ws<br>
full well it&#39;s a bad patch and is proposing it because he wants to push=
<br>
discussion towards a solution. Often trolling the a audience with bad<br>
patches is an effective way to motivate people to respond by writing<br>
better ones; Jeff has told me he often does exactly that.<br><br></blockquo=
te><div><br></div><div>mmmm kay.=C2=A0 Let&#39;s try to keep it technical, =
please.</div><div><br></div><div>2MB is a limit that has been discussed as =
a viable next-step, meeting with the most consensus.</div><div><br></div><d=
iv>2MB gets beyond the 1MB hard fork issue, while still remaining within a =
safety cap that should ensure the system does not go &quot;off the rails&qu=
ot; as some has predicted.</div><div><br></div><div>Security, privacy and c=
entralization are not going to disappear at 2MB.</div><div><br></div><div>F=
urther, a limited step gains valuable field data for judging whether furthe=
r steps are warranted - thus informing the &quot;better block size solution=
&quot; development process.</div><div><br></div><div>Finally, as stated in =
the initial PR, it is intended as a viable fallback should we reach a point=
 of criticality where the user community feels a block size increase is war=
ranted, yet cannot reach consensus on a fancy, all-consuming solution be it=
 20MB, flexcap, BIP 100, BIP 102, etc.</div><div><br></div><div>I am open t=
o suggestions for improving BIP 102.=C2=A0 The goal is a minimum complexity=
 fallback that others have previously agreed was a useful kick-the-can comp=
romise - a static 2MB cap.</div><div><br></div><div><br></div></div><br></d=
iv></div>

--089e0122aa626ed54e051b7a4eb9--