MIME-Version: 1.0
In-Reply-To: <CAHcfU-V7V8oerKPzuxE1iwZezFnQ1WTCC9g_rGmp7C56wpT19w@mail.gmail.com>
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
	<CAHcfU-V7V8oerKPzuxE1iwZezFnQ1WTCC9g_rGmp7C56wpT19w@mail.gmail.com>
Date: Sun, 7 Feb 2016 12:09:46 -0500
Message-ID: <CABsx9T0nXVUqZOfH0izsEwv3oU85GKmt8RLgLfXXZk5S-N1OZA@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11420fbac124f1052b3126ee
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
	megabytes
Precedence: list

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

As I feared, request on feedback for this specific BIP has devolved into a
general debate about the merits of soft-forks versus hard-forks (versus
semi-hard Kosher Free Range forks...).

I've replied to several people privately off-list to not waste people's
time rehashing arguments that have been argued to death in the past.

I do want to briefly address all of the concerns that stem from "what if a
significant fraction of hashpower (e.g. 25%) stick with the 1mb branch of
the chain."

Proof of work cannot be spoofed. If there is very little (a few percent) of
hashpower mining a minority chain, confirmations on that chain take orders
of magnitude longer.  I wrote about why the incentives are extremely strong
for only the stronger branch to survive here:
 http://gavinandresen.ninja/minority-branches

... the debate about whether or not that is correct doesn't belong here in
bitcoin-dev, in my humble opinion.

All of the security concerns I have seen flow from an assumption that
significant hashpower continues on the weaker branch. The BIP that is under
discussion assumes that analysis is correct. I have not seen any evidence
that it is not correct; all experience with previous forks (of both Bitcoin
and altcoins) is that the stronger branch survives and the weaker branch
very quickly dies.


As for the argument that creating and testing a patch for Core would take
longer than 28 days:

The glib answer is "people should just run Classic, then."

A less glib answer is it would be trivial to create a patch for Core that
accepted a more proof-of-work chain with larger blocks, but refused to mine
larger blocks.

That would be a trivial patch that would require very little testing
(extensive testing of 8 and 20mb blocks has already been done), and perhaps
would be the best compromise until we can agree on a permanent solution
that eliminates the arbitrary, contentious limits.

-- 
--
Gavin Andresen

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

<div dir=3D"ltr"><div class=3D"gmail_extra">As I feared, request on feedbac=
k for this specific BIP has devolved into a general debate about the merits=
 of soft-forks versus hard-forks (versus semi-hard Kosher Free Range forks.=
..).</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I=
&#39;ve replied to several people privately off-list to not waste people=
9;s time rehashing arguments that have been argued to death in the past.</d=
iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I do wan=
t to briefly address all of the concerns that stem from &quot;what if a sig=
nificant fraction of hashpower (e.g. 25%) stick with the 1mb branch of the =
chain.&quot;</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_=
extra">Proof of work cannot be spoofed. If there is very little (a few perc=
ent) of hashpower mining a minority chain, confirmations on that chain take=
 orders of magnitude longer.=C2=A0 I wrote about why the incentives are ext=
remely strong for only the stronger branch to survive here:</div><div class=
=3D"gmail_extra">=C2=A0<a href=3D"http://gavinandresen.ninja/minority-branc=
hes">http://gavinandresen.ninja/minority-branches</a></div><div class=3D"gm=
ail_extra"><br></div><div class=3D"gmail_extra">... the debate about whethe=
r or not that is correct doesn&#39;t belong here in bitcoin-dev, in my humb=
le opinion.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_e=
xtra">All of the security concerns I have seen flow from an assumption that=
 significant hashpower continues on the weaker branch. The BIP that is unde=
r discussion assumes that analysis is correct. I have not seen any evidence=
 that it is not correct; all experience with previous forks (of both Bitcoi=
n and altcoins) is that the stronger branch survives and the weaker branch =
very quickly dies.</div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra"><div><br></div><div>As for the argument that creating and test=
ing a patch for Core would take longer than 28 days:</div><div><br></div><d=
iv>The glib answer is &quot;people should just run Classic, then.&quot;</di=
v><div><br></div><div>A less glib answer is it would be trivial to create a=
 patch for Core that accepted a more proof-of-work chain with larger blocks=
, but refused to mine larger blocks.</div><div><br></div><div>That would be=
 a trivial patch that would require very little testing (extensive testing =
of 8 and 20mb blocks has already been done), and perhaps would be the best =
compromise until we can agree on a permanent solution that eliminates the a=
rbitrary, contentious limits.</div><div><br></div>-- <br><div class=3D"gmai=
l_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>--<br>Gavin Andres=
en<br></div><div><br></div></div></div></div></div>
</div></div>

--001a11420fbac124f1052b3126ee--