Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.169 as permitted sender)
	client-ip=209.85.214.169; envelope-from=gavinandresen@gmail.com;
	helo=mail-ob0-f169.google.com; 
MIME-Version: 1.0
In-Reply-To: <20150531070530.GD12966@muck>
References: <554BE0E1.5030001@bluematt.me>
	<CAFzgq-xByQ1E_33_m3UpXQFUkGc78HKnA=7XXMshANDuTkNsvA@mail.gmail.com>
	<20150531070530.GD12966@muck>
Date: Sun, 31 May 2015 08:51:04 -0400
Message-ID: <CABsx9T1jpOTxm3c4RYqK7sTF2YShL_ZYDsOWQuNZZXdBKa3Ytw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a113e12b8835273051760295e
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
Precedence: list

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

On Sun, May 31, 2015 at 3:05 AM, Peter Todd <pete@petertodd.org> wrote:

> Yeah, I'm pretty surprised myself that Gavin never accepted the
> compromises offered by others in this space for a slow growth solution
>

What compromise? I haven't seen a specific proposal that could be turned
into a pull request.


> Something important to note in Gavin Andresen's analysises of this issue
> is that he's using quite optimistic scenarios for how nodes are
> connected to each other.


NO I AM NOT.

I simulated a variety of connectivities; see the .cfg files at
  https://github.com/gavinandresen/bitcoin_miningsim

The results I give in the "are bigger blocks better" blog post are for
WORST CASE connectivity (one dominant big miner, multiple little miners,
big miner connects to only 30% of little miners, but all the little miners
connected directly to each other).


> For instance, assuming that connections between
> miners are direct is a very optimistic assumption


Again, I did not simulate all miners directly connected to each other.

I will note that miners are VERY HIGHLY connected today. It is in their
best interest to be highly connected to each other.


> that depends on a
> permissive, unregulated, environment where miners co-operate with each
> other - obviously that's easily subject to change!


Really? How is that easily subject to change? If it is easily subject to
change, do bigger blocks have any effect? Why are 1MB blocks not subject to
change?

I talk about "what if your government bans Bitcoin entirely" here:
   http://gavinandresen.ninja/big-blocks-and-tor

... and the issues are essentially the same, independent of block size.


-- 
--
Gavin Andresen

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, May 31, 2015 at 3:05 AM, 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">Yeah, I&#39;m pretty surprised myself that Gav=
in never accepted the<br>
compromises offered by others in this space for a slow growth solution<br><=
/blockquote><div><br></div><div>What compromise? I haven&#39;t seen a speci=
fic proposal that could be turned into a pull request.</div><div><br></div>=
<div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex">Something important to not=
e in Gavin Andresen&#39;s analysises of this issue<br>
is that he&#39;s using quite optimistic scenarios for how nodes are<br>
connected to each other.</blockquote><div><br></div><div>NO I AM NOT.</div>=
<div><br></div><div>I simulated a variety of connectivities; see the .cfg f=
iles at</div><div>=C2=A0=C2=A0<a href=3D"https://github.com/gavinandresen/b=
itcoin_miningsim">https://github.com/gavinandresen/bitcoin_miningsim</a></d=
iv><div><br></div><div>The results I give in the &quot;are bigger blocks be=
tter&quot; blog post are for WORST CASE connectivity (one dominant big mine=
r, multiple little miners, big miner connects to only 30% of little miners,=
 but all the little miners connected directly to each other).</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"> For instance, assuming that connections between<=
br>
miners are direct is a very optimistic assumption</blockquote><div><br></di=
v><div>Again, I did not simulate all miners directly connected to each othe=
r.</div><div><br></div><div>I will note that miners are VERY HIGHLY connect=
ed today. It is in their best interest to be highly connected to each other=
.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex"> that depends on a<br>
permissive, unregulated, environment where miners co-operate with each<br>
other - obviously that&#39;s easily subject to change! </blockquote><div><b=
r></div><div>Really? How is that easily subject to change? If it is easily =
subject to change, do bigger blocks have any effect? Why are 1MB blocks not=
 subject to change?</div><div><br></div><div>I talk about &quot;what if you=
r government bans Bitcoin entirely&quot; here:</div><div>=C2=A0 =C2=A0<a hr=
ef=3D"http://gavinandresen.ninja/big-blocks-and-tor">http://gavinandresen.n=
inja/big-blocks-and-tor</a></div><div><br></div><div>... and the issues are=
 essentially the same, independent of block size.</div><div><br></div></div=
><div><br></div>-- <br><div class=3D"gmail_signature">--<br>Gavin Andresen<=
br></div>
</div></div>

--001a113e12b8835273051760295e--