Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E9354E53 for ; Thu, 27 Aug 2015 00:48:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DFA29126 for ; Thu, 27 Aug 2015 00:48:44 +0000 (UTC) Received: by labgv11 with SMTP id gv11so2359021lab.2 for ; Wed, 26 Aug 2015 17:48:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5xoFAmC/C8zh/BagfKxliY3GkwpKu212KQ15XJeEpaM=; b=GZOhWsyPbtY/KdS7H4ndWtdKb3/B2WOvTFdlP/FWjJGs7yKFGmU5OQlstB3nG1UKo3 3GMl1HEVoA6U4ggTipI7f/nCcvw3HgCjVMLwaBmmHH3hhc5/w7nDz0WQa0CcaqPPYwOJ vkAsn4JKIUE+5bxpvuYMYmdDJp4oFsQAgPxiGEm24ANmWD0xBwR+OPyI636LMlJne4jQ KDZezeLdhn5NX3EdPtXGoZ1URpfOJpFbOcmGY5OGrEZCtFSzXsmxRYrnbt1NMaCAg2DX lUxKvX6bMAmfXWy7eMw6PI9TAAquXIIsm7aaS2J/mn7ANvxDDv0YRSbyca6OE5I8dNCG zlmg== X-Gm-Message-State: ALoCoQlDaeoelLvqxqdnzUhbVM+YzzeVAUhgbG9H36nESMIw/t4KyoyoqWAy5KjjIRaiwTPL/iEZ MIME-Version: 1.0 X-Received: by 10.152.179.170 with SMTP id dh10mr1135378lac.22.1440636522898; Wed, 26 Aug 2015 17:48:42 -0700 (PDT) Received: by 10.25.15.22 with HTTP; Wed, 26 Aug 2015 17:48:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Aug 2015 02:48:42 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Daniele Pinna Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Unlimited Max Blocksize (reprise) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 00:48:46 -0000 On Thu, Aug 27, 2015 at 12:22 AM, Daniele Pinna via bitcoin-dev wrote: > I don't get how it's very risky to have the Mike and Gavin redirect the > course of the bitcoin protocol but it's totally fine to consider complex > miner voting protocols as a hard fork option. Maybe this helps undesrtanding the risks of a contentious/schism hardfork: https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR137 That section can be greatly improved though. > I believe that this community has not given due weight to the analysis > proposed by Peter__R on the existence of fee markets with uncapped max > blocksizes. The critiques made toward his work were in no way definitive and > discussion just stopped. Is it the math that bothers people? I have only skimmed the document, but I believe its conclusions (or some of them) are right for the current propagation code. The assumption may not stand if we move to something like IBLT though. I believe that document also proves that it is irrational/noncompetitive for miners to include ANY free transactions at all (like they currently do). But the analysis is about the effect of the maximum block size on fees: there's more effects of that consensus rule. The most important one being that it limits mining centralization (and centralization in general). This is true for at least 2 reasons: one is related to block propagation and it is what is usually described. At a bigger scale (even with crazy assumptions like constant time infinite bandwidth, instant [superluminal] communication, zkSNARKS block validity proofs ) minimum CPU costs will be something to limit through the maximum block size consensus rule. There's a scale at which the minimum CPU costs for a miner to be competitive may be so high that some small miners without the resources to meet that minimum will become unprofitable. Admittedly we're not near that scale yet, but if something to take into account. > The main critique to uncapped max blocksizes which I've heard stems from our > incapacity to quantify the advantages that large miners have over smaller > ones. There are some simulations. See: http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners The goal of https://github.com/bitcoin/bitcoin/pull/6382 is to allow people to do more realistic simulations (by using real full nodes). That doesn't mean that more simplified simulations are worthless, but I didn't want people to have to create their own testchain every time they want to simulate a different size, like rusty had to do for: http://rusty.ozlabs.org/?p=509 So the "incapacity to quantify the advantages that large miners have over smaller ones" doesn't really exist. It would be nice to have more data about this (more sizes, more network topologies, etc) though. > As I will show in an upcoming paper, these advantages do not stem from > the act of propagating large blocks but rather from the block subsidies > which allow miners to mine unnecessary large blocks irregardless of the fees > contained therein. One typical example is Peter Todd's suggested attack > whereby a miner creates a massive block filled with spam transactions that > pay himself solely to slow down the rest of the network and gain an > advantage. Putting aside the increased orphan risk arising from the > propagation of such a large block, this attack would never be viable if it > weren't for the existence of current block subsidies. Although smaller subsidies will remove some problems we currently have, for example, SPV mining (there's no incentive to SPV mine worthless empty blocks), I don't understand your claim that they will also solve mining centralization problems related to block propagation. > As such, exponential increases to the max blocksize make perfect sense since > the block reward decreases exponentially also. All arguments invoking rates > of technological advances (see Gavin's original posts) don't mean anything. I really dislike basing the consensus rules on predictions about future technology. For all I know, a terrible war could destroy half of the global internet infrastructure in the next 5 years. I prefer simpler increments like in bip102 (although I don't have the data to know if 2MB is safe mining-centralization-wise at this point [when mining centralization is pretty bad]). Arguments against that kind of change are usually along the lines "then we will have to repeat this same discussion in 1 or 2 years". I believe that with the proper simulation tools being deployed and a better general understanding of what the concerns are, the conversation should be much simpler the next time. > Rational miners will NOT be incentivized to mine gargantuan spam filled > blocks in the presence of a vanishing block reward. Actually some simulations show they in fact have incentive to do just that in some cases. But more importantly, we shouldn't assume that all attackers are rational miners. Maybe a potential attacker is a secret service or a financial cartel attempting to destroy Bitcoin for whatever reason. > I truly hope this matter gets the consideration it deserves. Particularly > with the upcoming scaling workshops. I truly hope that the discussion can move forward into more productive territories after the workshop, and I'm particularly interested in Peter R's presentation, even if I haven't found the time to read his paper yet. Even if fees are not the main reason why we want to have a block size maximum, fees are certainly very relevant and anything that he has mathematically proven in that regard will be useful to this discussion. > On Aug 21, 2015 11:35 PM, "Daniele Pinna" wrote: > > "I ran some simulations, and if blocks take 20 seconds to propagate, a > network with a miner that has 30% of the hashing power will get 30.3% of the > blocks." > > Peter_R's analysis of fee markets in the absence of blocksize limits [1] > shows that the hashrate advantage of a large miner is a side-effect of > coinbase subsidization. As the block rewards get smaller, so will large > miner advantages. An easy way to think about this is as follows: > > Currently, the main critique of larger blocksizes is that we'll connected > miners can cut out smaller miners by gratuitously filling up blocks with > self-paying transactions. This only works because block subsidies exist. The > moment block rewards become comparable to block TX fees, this exploit ceases > to be functional. > > Basically, large miners will still be forced to move full blocks, but it > will go against their interest to fill them with spam since their main > source of income is the fees themselves. As a result, large miners (unlike > smaller ones) will lose the incentive to mine an un full block this evening > the playing field. > > In this context, large blocksizes as proposed by BIP100-101 hope to > stimulate the increase of TX fees by augmenting the network's capacity. The > sooner block rewards become comparable to block fees, the sooner we will get > rid of mine centralization. > > Dpinna > > [1] > http://www.scribd.com/mobile/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >