Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.160.169 as permitted sender)
	client-ip=209.85.160.169;
	envelope-from=stephencalebmorse@gmail.com;
	helo=mail-yk0-f169.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANe1mWz_wDAFL2piyLeOxEnMxHCQaTnGLQA6f9jZvLEmbMj6Zw@mail.gmail.com>
References: <CANe1mWz_wDAFL2piyLeOxEnMxHCQaTnGLQA6f9jZvLEmbMj6Zw@mail.gmail.com>
Date: Mon, 1 Jun 2015 15:02:12 -0400
Message-ID: <CABHVRKSm08T7ik4Ozd-WgMTrkT2c0waKDwg6Ma+ZMTWWeevfAw@mail.gmail.com>
From: Stephen Morse <stephencalebmorse@gmail.com>
To: Jim Phillips <jim@ergophobia.org>
Content-Type: multipart/alternative; boundary=001a11395e8ea31ad205177976bd
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Why do we need a MAX_BLOCK_SIZE at all?
Precedence: list

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

This exact question came up on the Bitcoin Stack Exchange once. I gave an
answer here:
http://bitcoin.stackexchange.com/questions/37292/whats-the-purpose-of-a-maximum-block-size/37303#37303

On Mon, Jun 1, 2015 at 2:32 PM, Jim Phillips <jim@ergophobia.org> wrote:

> Ok, I understand at least some of the reason that blocks have to be kept
> to a certain size. I get that blocks which are too big will be hard to
> propagate by relays. Miners will have more trouble uploading the large
> blocks to the network once they've found a hash. We need block size
> constraints to create a fee economy for the miners.
>
> But these all sound to me like issues that affect some, but not others. So
> it seems to me like it ought to be a configurable setting. We've already
> witnessed with last week's stress test that most miners aren't even
> creating 1MB blocks but are still using the software defaults of 730k. If
> there are configurable limits, why does there have to be a hard limit?
> Can't miners just use the configurable limit to decide what size blocks
> they can afford to and are thus willing to create? They could just as
> easily use that to create a fee economy. If the miners with the most
> hashpower are not willing to mine blocks larger than 1 or 2 megs, then they
> are able to slow down confirmations of transactions. It may take several
> blocks before a miner willing to include a particular transaction finds a
> block. This would actually force miners to compete with each other and find
> a block size naturally instead of having it forced on them by the protocol.
> Relays would be able to participate in that process by restricting the
> miners ability to propagate large blocks. You know, like what happens in a
> FREE MARKET economy, without burdensome regulation which can be manipulated
> through politics? Isn't that what's really happening right now? Different
> political factions with different agendas are fighting over how best to
> regulate the Bitcoin protocol.
>
> I know the limit was originally put in place to prevent spamming. But that
> was when we were mining with CPUs and just beginning to see the occasional
> GPU which could take control over the network and maliciously spam large
> blocks. But with ASIC mining now catching up to Moore's Law, that's not
> really an issue anymore. No one malicious entity can really just take over
> the network now without spending more money than it's worth -- and that's
> just going to get truer with time as hashpower continues to grow. And it's
> not like the hard limit really does anything anymore to prevent spamming.
> If a spammer wants to create thousands or millions of transactions, a hard
> limit on the block size isn't going to stop him.. He'll just fill up the
> mempool or UTXO database instead of someone's block database.. And block
> storage media is generally the cheapest storage.. I mean they could be
> written to tape and be just as valid as if they're stored in DRAM. Combine
> that with pruning, and block storage costs are almost a non-issue for
> anyone who isn't running an archival node.
>
> And can't relay nodes just configure a limit on the size of blocks they
> will relay? Sure they'd still need to download a big block occasionally,
> but that's not really that big a deal, and they're under no obligation to
> propagate it.. Even if it's a 2GB block, it'll get downloaded eventually.
> It's only if it gets to the point where the average home connection is too
> slow to keep up with the transaction & block flow that there's any real
> issue there, and that would happen regardless of how big the blocks are. I
> personally would much prefer to see hardware limits act as the bottleneck
> than to introduce an artificial bottleneck into the protocol that has to be
> adjusted regularly. The software and protocol are TECHNICALLY capable of
> scaling to handle the world's entire transaction set. The real issue with
> scaling to this size is limitations on hardware, which are regulated by
> Moore's Law. Why do we need arbitrary soft limits? Why can't we allow
> Bitcoin to grow naturally within the ever increasing limits of our
> hardware? Is it because nobody will ever need more than 640k of RAM?
>
> Am I missing something here? Is there some big reason that I'm overlooking
> why there has to be some hard-coded limit on the block size that affects
> the entire network and creates ongoing issues in the future?
>
> --
>
> *James G. Phillips IV*
> <https://plus.google.com/u/0/113107039501292625391/posts>
>
> *"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
> -- David Ogilvy*
>
>  *This message was created with 100% recycled electrons. Please think
> twice before printing.*
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

<div dir=3D"ltr">This exact question came up on the Bitcoin Stack Exchange =
once. I gave an answer here:=C2=A0<a href=3D"http://bitcoin.stackexchange.c=
om/questions/37292/whats-the-purpose-of-a-maximum-block-size/37303#37303">h=
ttp://bitcoin.stackexchange.com/questions/37292/whats-the-purpose-of-a-maxi=
mum-block-size/37303#37303</a></div><div class=3D"gmail_extra"><br><div cla=
ss=3D"gmail_quote">On Mon, Jun 1, 2015 at 2:32 PM, Jim Phillips <span dir=
=3D"ltr">&lt;<a href=3D"mailto:jim@ergophobia.org" target=3D"_blank">jim@er=
gophobia.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">Ok, I understand at least some of the reason that blocks have to=
 be kept to a certain size. I get that blocks which are too big will be har=
d to propagate by relays. Miners will have more trouble uploading the large=
 blocks to the network once they&#39;ve found a hash. We need block size co=
nstraints to create a fee economy for the miners.<div><br>But these all sou=
nd to me like issues that affect some, but not others. So it seems to me li=
ke it ought to be a configurable setting. We&#39;ve already witnessed with =
last week&#39;s stress test that most miners aren&#39;t even creating 1MB b=
locks but are still using the software defaults of 730k. If there are confi=
gurable limits, why does there have to be a hard limit? Can&#39;t miners ju=
st use the configurable limit to decide what size blocks they can afford to=
 and are thus willing to create? They could just as easily use that to crea=
te a fee economy. If the miners with the most hashpower are not willing to =
mine blocks larger than 1 or 2 megs, then they are able to slow down confir=
mations of transactions. It may take several blocks before a miner willing =
to include a particular transaction finds a block. This would actually forc=
e miners to compete with each other and find a block size naturally instead=
 of having it forced on them by the protocol. Relays would be able to parti=
cipate in that process by restricting the miners ability to propagate large=
 blocks. You know, like what happens in a FREE MARKET=C2=A0economy, without=
 burdensome regulation which can be manipulated through politics? Isn&#39;t=
 that what&#39;s really happening right now? Different political factions w=
ith different agendas are fighting over how best to regulate the Bitcoin pr=
otocol.<br><br></div><div>I know the limit was originally put in place to p=
revent spamming. But that was when we were mining with CPUs and just beginn=
ing to see the occasional GPU which could take control over the network and=
 maliciously spam large blocks. But with ASIC mining now catching up to Moo=
re&#39;s Law, that&#39;s not really an issue anymore. No one malicious enti=
ty can really just take over the network now without spending more money th=
an it&#39;s worth -- and that&#39;s just going to get truer with time as ha=
shpower continues to grow. And it&#39;s not like the hard limit really does=
 anything anymore to prevent spamming. If a spammer wants to create thousan=
ds or millions of transactions, a hard limit on the block size isn&#39;t go=
ing to stop him.. He&#39;ll just fill up the mempool or UTXO database inste=
ad of someone&#39;s block database.. And block storage media is generally t=
he cheapest storage.. I mean they could be written to tape and be just as v=
alid as if they&#39;re stored in DRAM. Combine that with pruning, and block=
 storage costs are almost a non-issue for anyone who isn&#39;t running an a=
rchival node.</div><div><br>And can&#39;t relay nodes just configure a limi=
t on the size of blocks they will relay? Sure they&#39;d still need to down=
load a big block occasionally, but that&#39;s not really that big a deal, a=
nd they&#39;re under no obligation to propagate it.. Even if it&#39;s a 2GB=
 block, it&#39;ll get downloaded eventually. It&#39;s only if it gets to th=
e point where the average home connection is too slow to keep up with the t=
ransaction &amp; block flow that there&#39;s any real issue there, and that=
 would happen regardless of how big the blocks are. I personally would much=
 prefer to see hardware limits act as the bottleneck than to introduce an a=
rtificial bottleneck into the protocol that has to be adjusted regularly.=
=C2=A0The software and protocol are TECHNICALLY capable of scaling to handl=
e the world&#39;s entire transaction set. The real issue with scaling to th=
is size is limitations on hardware, which are regulated by Moore&#39;s Law.=
 Why do we need arbitrary soft limits? Why can&#39;t we allow Bitcoin to gr=
ow naturally within the ever increasing limits of our hardware? Is it becau=
se nobody will ever need more than 640k of RAM?<br><br></div><div>Am I miss=
ing something here? Is there some big reason that I&#39;m overlooking why t=
here has to be some hard-coded limit on the block size that affects the ent=
ire network and creates ongoing issues in the future?</div><div><br><div><d=
iv><div>--</div><div><br><div><b>James G. Phillips IV</b>=C2=A0<a href=3D"h=
ttps://plus.google.com/u/0/113107039501292625391/posts" style=3D"font-size:=
x-small" target=3D"_blank"><img src=3D"https://ssl.gstatic.com/images/icons=
/gplus-16.png"></a></div></div><div><font size=3D"1"><i>&quot;Don&#39;t bun=
t. Aim out of the ball park. Aim for the company of immortals.&quot; -- Dav=
id Ogilvy<br></i></font><div><font size=3D"1"><br></font></div></div><div><=
font size=3D"1"><img src=3D"http://findicons.com/files/icons/1156/fugue/16/=
leaf.png">=C2=A0<em style=3D"font-family:verdana,geneva,sans-serif;line-hei=
ght:16px;color:green;background-color:rgb(255,255,255)">This message was cr=
eated with 100% recycled electrons. Please think twice before printing.</em=
></font></div></div></div>
</div></div>
<br>-----------------------------------------------------------------------=
-------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>

--001a11395e8ea31ad205177976bd--