Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.52 as permitted sender)
	client-ip=209.85.215.52; envelope-from=gavinandresen@gmail.com;
	helo=mail-la0-f52.google.com; 
MIME-Version: 1.0
In-Reply-To: <CABm2gDr4G7V5OLfiFq0onGNb3HCWHk9K46FtVcLOVetvxiLqRg@mail.gmail.com>
References: <554BE0E1.5030001@bluematt.me>
	<CABsx9T2ysKj5HVbN_7_o33fMehs4KH6E_R583Mt_VPC4gDA0LQ@mail.gmail.com>
	<5568F567.3050608@bluematt.me>
	<CABsx9T3__mHZ_kseRg-w-x2=8v78QJLhe+BWPezv+hpbFCufpw@mail.gmail.com>
	<556A1046.50807@bluematt.me>
	<CABsx9T3qPiQ+PL3ZNT+QJzw4ALEzKjMjC4=uEKTG+4vVPdXr-g@mail.gmail.com>
	<CABm2gDoE5kbE2cnFzZPAOZbHMdXBaZG7pB7c6dovj=1unPentw@mail.gmail.com>
	<CABsx9T0SVW9ASBH=Xyet5EKQtjAoJ7nLpAab5_yLQdUo=QpV7w@mail.gmail.com>
	<CABm2gDr4G7V5OLfiFq0onGNb3HCWHk9K46FtVcLOVetvxiLqRg@mail.gmail.com>
Date: Sun, 31 May 2015 11:08:12 -0400
Message-ID: <CABsx9T3_MVw6WBv8b35E0+NdJreRTbHHbweckdO=XZu4LRcOEQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=001a11c2b616efdad905176213df
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
Precedence: list

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

On Sun, May 31, 2015 at 10:59 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote=
:

> Whatever...let's use the current subsidies, the same argument applies,
> it's just 20 + 25 =3D 45 btc per block for miner B vs 27 btc for miner B.
> Miner B would still go out of business, bigger blocks still mean more
> mining and validation centralization
>
Sorry, but that's ridiculous.

If Miner B is leaving 18BTC per block on the table because they have bad
connectivity, then they need to pay for better connectivity.

If you are arguing "I should be able to mine on a 56K modem connection from
the middle of the Sahara" then we're going to have to agree to disagree.

So: what is your specific proposal for minimum requirements for
connectivity to run a full node? The 20MB number comes from estimating
costs to run a full node, and as my back-and-forth to Chang Wung shows, the
costs are not excessive.

--=20
--
Gavin Andresen

--001a11c2b616efdad905176213df
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 10:59 AM, Jorge Tim=C3=B3n <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Whatever...let=
&#39;s use the current subsidies, the same argument applies, it&#39;s just =
20 + 25 =3D 45 btc per block for miner B vs 27 btc for miner B.<br>
Miner B would still go out of business, bigger blocks still mean more minin=
g and validation centralization</p></blockquote><div>Sorry, but that&#39;s =
ridiculous.</div><div><br></div><div>If Miner B is leaving 18BTC per block =
on the table because they have bad connectivity, then they need to pay for =
better connectivity.</div><div><br></div><div>If you are arguing &quot;I sh=
ould be able to mine on a 56K modem connection from the middle of the Sahar=
a&quot; then we&#39;re going to have to agree to disagree.</div><div><br></=
div><div>So: what is your specific proposal for minimum requirements for co=
nnectivity to run a full node? The 20MB number comes from estimating costs =
to run a full node, and as my back-and-forth to Chang Wung shows, the costs=
 are not excessive.</div><div>=C2=A0</div></div>-- <br><div class=3D"gmail_=
signature">--<br>Gavin Andresen<br></div>
</div></div>

--001a11c2b616efdad905176213df--