MIME-Version: 1.0
In-Reply-To: <CABsx9T3_MVw6WBv8b35E0+NdJreRTbHHbweckdO=XZu4LRcOEQ@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>
	<CABsx9T3_MVw6WBv8b35E0+NdJreRTbHHbweckdO=XZu4LRcOEQ@mail.gmail.com>
Date: Sun, 31 May 2015 17:45:01 +0200
Message-ID: <CABm2gDobPy+j4+7F=boUG4DkbzOUwcWTT2iPorCiptFwgE3yJw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=047d7ba97f1aa303510517629734
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
Precedence: list

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

On May 31, 2015 5:08 PM, "Gavin Andresen" <gavinandresen@gmail.com> wrote:
>
> On Sun, May 31, 2015 at 10:59 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wro=
te:
>>
>> 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.

Well, I was assuming they just can't upgrade their connection (without
moving thei operations to another place). Maybe that assumption is
ridiculous as well.

> 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.

No, I'm not suggesting that.

> 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.

Well, you were I think assuming a new desktop connecting from somewhere in
the US. I would be more confortable with an eee pc from a hotel in India,
for example. But yeah, targeting some concrete minimum specs seems like the
right approach for deciding "how far to go when increasing centralization".

But "hitting the limit will be chaos" seems to imply that completely
removing the consensus maximum blocksize is the only logical solution. What
happens when we hit the limit next time? When do we stop kicking the can
down the road? When do we voluntarily get that "chaos"?
Again, "that's too far away in the future to worry about it" is not a very
conving answer to me.

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

<p dir=3D"ltr"><br>
On May 31, 2015 5:08 PM, &quot;Gavin Andresen&quot; &lt;<a href=3D"mailto:g=
avinandresen@gmail.com">gavinandresen@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Sun, May 31, 2015 at 10:59 AM, Jorge Tim=C3=B3n &lt;jtimon@jtimon.c=
c&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; 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 f=
or miner B.<br>
&gt;&gt; Miner B would still go out of business, bigger blocks still mean m=
ore mining and validation centralization<br>
&gt;<br>
&gt; Sorry, but that&#39;s ridiculous.<br>
&gt;<br>
&gt; If Miner B is leaving 18BTC per block on the table because they have b=
ad connectivity, then they need to pay for better connectivity.</p>
<p dir=3D"ltr">Well, I was assuming they just can&#39;t upgrade their conne=
ction (without moving thei operations to another place). Maybe that assumpt=
ion is ridiculous as well.</p>
<p dir=3D"ltr">&gt; If you are arguing &quot;I should be able to mine on a =
56K modem connection from the middle of the Sahara&quot; then we&#39;re goi=
ng to have to agree to disagree.</p>
<p dir=3D"ltr">No, I&#39;m not suggesting that.</p>
<p dir=3D"ltr">&gt; So: what is your specific proposal for minimum requirem=
ents for connectivity to run a full node? The 20MB number comes from estima=
ting costs to run a full node, and as my back-and-forth to Chang Wung shows=
, the costs are not excessive.</p>
<p dir=3D"ltr">Well, you were I think assuming a new desktop connecting fro=
m somewhere in the US. I would be more confortable with an eee pc from a ho=
tel in India, for example. But yeah, targeting some concrete minimum specs =
seems like the right approach for deciding &quot;how far to go when increas=
ing centralization&quot;.</p>
<p dir=3D"ltr">But &quot;hitting the limit will be chaos&quot; seems to imp=
ly that completely removing the consensus maximum blocksize is the only log=
ical solution. What happens when we hit the limit next time? When do we sto=
p kicking the can down the road? When do we voluntarily get that &quot;chao=
s&quot;?<br>
Again, &quot;that&#39;s too far away in the future to worry about it&quot; =
is not a very conving answer to me.<br>
</p>

--047d7ba97f1aa303510517629734--