diff options
| author | Stephen Morse <stephencalebmorse@gmail.com> | 2015-06-01 15:02:12 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-01 19:02:20 +0000 |
| commit | 6b4ccf98af5b4863312bb6a8d0abaf190694c8d8 (patch) | |
| tree | 198a8045a4cdea42770c0275da8b90c03921dc36 | |
| parent | fdebcb386d14383cb40f898c5affea61565482f5 (diff) | |
| download | pi-bitcoindev-6b4ccf98af5b4863312bb6a8d0abaf190694c8d8.tar.gz pi-bitcoindev-6b4ccf98af5b4863312bb6a8d0abaf190694c8d8.zip | |
Re: [Bitcoin-development] Why do we need a MAX_BLOCK_SIZE at all?
| -rw-r--r-- | c5/944e09f712cc8846d3d0844384e09175b34fe9 | 250 |
1 files changed, 250 insertions, 0 deletions
diff --git a/c5/944e09f712cc8846d3d0844384e09175b34fe9 b/c5/944e09f712cc8846d3d0844384e09175b34fe9 new file mode 100644 index 000000000..5e25299d8 --- /dev/null +++ b/c5/944e09f712cc8846d3d0844384e09175b34fe9 @@ -0,0 +1,250 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <stephencalebmorse@gmail.com>) id 1YzUya-0003OC-No + for bitcoin-development@lists.sourceforge.net; + Mon, 01 Jun 2015 19:02:20 +0000 +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; +Received: from mail-yk0-f169.google.com ([209.85.160.169]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1YzUyY-0002DI-0E + for bitcoin-development@lists.sourceforge.net; + Mon, 01 Jun 2015 19:02:20 +0000 +Received: by yked142 with SMTP id d142so46470600yke.3 + for <bitcoin-development@lists.sourceforge.net>; + Mon, 01 Jun 2015 12:02:12 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.170.134.1 with SMTP id a1mr3404068ykc.30.1433185332434; Mon, + 01 Jun 2015 12:02:12 -0700 (PDT) +Received: by 10.13.245.70 with HTTP; Mon, 1 Jun 2015 12:02:12 -0700 (PDT) +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 +X-Spam-Score: -0.6 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (stephencalebmorse[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature + 0.0 T_REMOTE_IMAGE Message contains an external image + -0.0 AWL AWL: Adjusted score from AWL reputation of From: address +X-Headers-End: 1YzUyY-0002DI-0E +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Why do we need a MAX_BLOCK_SIZE at all? +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Mon, 01 Jun 2015 19:02:20 -0000 + +--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"><<a href=3D"mailto:jim@ergophobia.org" target=3D"_blank">jim@er= +gophobia.org</a>></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'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've already witnessed with = +last week's stress test that most miners aren'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'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't= + that what'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's Law, that'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's worth -- and that's just going to get truer with time as ha= +shpower continues to grow. And it'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't go= +ing to stop him.. He'll just fill up the mempool or UTXO database inste= +ad of someone'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're stored in DRAM. Combine that with pruning, and block= + storage costs are almost a non-issue for anyone who isn't running an a= +rchival node.</div><div><br>And can't relay nodes just configure a limi= +t on the size of blocks they will relay? Sure they'd still need to down= +load a big block occasionally, but that's not really that big a deal, a= +nd 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 th= +e point where the average home connection is too slow to keep up with the t= +ransaction & 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 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's entire transaction set. The real issue with scaling to th= +is 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 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'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>"Don't bun= +t. Aim out of the ball park. Aim for the company of immortals." -- 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-- + + |