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 ) 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 ; 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: References: Date: Mon, 1 Jun 2015 15:02:12 -0400 Message-ID: From: Stephen Morse To: Jim Phillips 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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* > > > *"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
This exact question came up on the Bitcoin Stack Exchange = once. I gave an answer here:=C2=A0h= ttp://bitcoin.stackexchange.com/questions/37292/whats-the-purpose-of-a-maxi= mum-block-size/37303#37303

On Mon, Jun 1, 2015 at 2:32 PM, Jim Phillips <jim@er= gophobia.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 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.

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.

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.

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?

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?

--

James G. Phillips IV=C2=A0
"Don't bun= t. Aim out of the ball park. Aim for the company of immortals." -- Dav= id Ogilvy

<= font size=3D"1">=C2=A0This message was cr= eated with 100% recycled electrons. Please think twice before printing.

-----------------------------------------------------------------------= -------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a11395e8ea31ad205177976bd--