From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YyTeh-0003C9-OC for bitcoin-development@lists.sourceforge.net; Fri, 29 May 2015 23:25:35 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bluematt.me designates 192.241.179.72 as permitted sender) client-ip=192.241.179.72; envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; Received: from mail.bluematt.me ([192.241.179.72]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YyTeg-0004uB-He for bitcoin-development@lists.sourceforge.net; Fri, 29 May 2015 23:25:35 +0000 Received: from [172.17.0.1] (gw.vpn.bluematt.me [162.243.132.6]) by mail.bluematt.me (Postfix) with ESMTPSA id 6F68154DA8; Fri, 29 May 2015 23:25:28 +0000 (UTC) Message-ID: <5568F567.3050608@bluematt.me> Date: Fri, 29 May 2015 23:25:27 +0000 From: Matt Corallo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Gavin Andresen References: <554BE0E1.5030001@bluematt.me> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.5 (-) 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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1YyTeg-0004uB-He Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Block Size Increase Requirements 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: Fri, 29 May 2015 23:25:35 -0000 On 05/29/15 22:36, Gavin Andresen wrote: > Matt brought this up on Twitter, I have no idea why I didn't respond > weeks ago (busy writing blog posts, probably): > > On Thu, May 7, 2015 at 6:02 PM, Matt Corallo > wrote: > > > > * Though there are many proposals floating around which could > significantly decrease block propagation latency, none of them are > implemented today. > > > If block propagation isn't fixed, then mines have a strong incentive to > create smaller blocks. > > So the max block size is irrelevant, it won't get hit. Sadly, this is very far from the whole story. The issue of miners optimizing for returns has been discussed several times during this discussion, and, sadly, miners who are geographically colocated who are optimizing for returns with a free-floating blocksize will optimize away 50% of the network! > > In addition, I'd expect to > see analysis of how these systems perform in the worst-case, not just > packet-loss-wise, but in the face of miners attempting to break the > system. > > > See http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners for > analysis of "but that means bigger miners can get an advantage" argument. > > Executive summary: if little miners are stupid and produce huge blocks, > then yes, big miners have an advantage. I'll talk about transaction fees in a second, but there are several problems with this already. As pointed out in the original mail, gfw has already been known to interfere with Bitcoin P2P traffic. So now by "little" miners, you mean any miner who is not located in mainland China? Whats worse, the disadvantage is symmetric - little miners are at a disadvantage when *anyone* mines a bigger block, and miners dont even have to be "evil" for this to happen - just optimize for profits. > But they're not, so they won't. I dont know what you're referring to with this. Are you claiming little miners today optimize for relay times and have good visibility into the Bitcoin network and calculate an optimal block size based on this (or would with a 20MB block size)? > Until the block reward goes away, and assuming transaction fees become > an important source of revenue for miners. > I think it is too early to worry about that; see: > > http://gavinandresen.ninja/when-the-block-reward-goes-away You dont make any points here with which I can argue, but let me respond with the reason /I/ think it is a problem worth thinking a little bit about...If we increase the blocksize sufficiently such that transaction fees are not the way in which miners make their money, then either miners are not being funded (ie hashpower has to drop to very little), or the only people mining/funding miners are large orgs who are "running" Bitcoin (ie the web wallets, payment processors, big merchants, and exchanges of the world). Sadly, this is no longer a decentralized Bitcoin and is, in fact, pretty much how the banking world works today. I'm not sure who, if anyone, claims Bitcoin is novel or interesting for any reason other than its decentralization properties, and, in a world which you are apparently proposing, the "natural" course of things is to very strongly centralize. > * I'd very much like to see someone working on better scaling > technology, both in terms of development and in terms of getting > traction in the marketplace. > > > Ok. What does this have to do with the max block size? > > Are you arguing that work won't happen if the max block size increases? Yes, I am arguing that by increasing the blocksize the incentives to actually make Bitcoin scale go away. Even if amazing technologies get built, no one will have any reason to use them. > * I'd like to see some better conclusions to the discussion around > > long-term incentives within the system. > > > Again, see http://gavinandresen.ninja/when-the-block-reward-goes-away > for what I think about that.