Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id ADCC9E47 for ; Wed, 26 Aug 2015 22:22:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BC82C10C for ; Wed, 26 Aug 2015 22:22:42 +0000 (UTC) Received: by iodv127 with SMTP id v127so36759432iod.3 for ; Wed, 26 Aug 2015 15:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=DueQ08+pXsY12sI7ExucY3cTiyTjpZgm6+B8Jwt6jI4=; b=q1JRepXex/dFMF633LlA8aEmuCx+7dE1+W7TI2FHagIMPkwxlS6erlAJ7Ji+DGHleF m52j3baZAhsncpHXbJ2jc5N61Y0SK5TS5lw8JaYUEAbUMyisP8I/161hgV1j4e+2dvM8 qs8l6aeNr9EbaVXOooXuvLRN677I9DwNQql2RZ9eR2lals08f8zdZIOZcyXeWyrOJx1K LCwKSP7Yo+1FN5nVtrIH0DK0Z8QVSsfpeyvv9dQrE4cFT7tLgWWc/u+MaQ7M8G4XNKLd eAxRgPjbfsTebYMUyzCQ9miFNSpvmmzQFhC5VNdm5/f7iTsuQ+thvQakFKZumSC9G3VI rA6w== MIME-Version: 1.0 X-Received: by 10.107.129.160 with SMTP id l32mr6672934ioi.158.1440627762142; Wed, 26 Aug 2015 15:22:42 -0700 (PDT) Received: by 10.50.30.198 with HTTP; Wed, 26 Aug 2015 15:22:42 -0700 (PDT) Received: by 10.50.30.198 with HTTP; Wed, 26 Aug 2015 15:22:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Aug 2015 00:22:42 +0200 Message-ID: From: Daniele Pinna To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a113ec3a6043b6b051e3e4a70 X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 Subject: [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: Wed, 26 Aug 2015 22:22:44 -0000 --001a113ec3a6043b6b051e3e4a70 Content-Type: text/plain; charset=UTF-8 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. 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? If his work stands the test of scrutiny, then a controlled raising of the max blocksize in the interim to ease into the fee market dynamic described is the best option. Possibly a stepwise BIP101 where the community hardforks every two years until we all trust the fee market dynamics. 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. 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. 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. Rational miners will NOT be incentivized to mine gargantuan spam filled blocks in the presence of a vanishing block reward. I truly hope this matter gets the consideration it deserves. Particularly with the upcoming scaling workshops. Dpinna 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 --001a113ec3a6043b6b051e3e4a70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 fin= e to consider complex miner voting protocols as a hard fork option.

I believe that this community has not given due weight to th= e analysis proposed by Peter__R on the existence of fee markets with=C2=A0 = 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?=

If his work stands the test of scrutiny, then a controlled r= aising of the max blocksize in the interim to ease into the fee market dyna= mic described is the best option. Possibly a stepwise BIP101 where the comm= unity hardforks every two years until we all trust the fee market dynamics.=

The main critique to uncapped max blocksizes which I've = heard stems from our incapacity to quantify the advantages that large miner= s have over smaller ones. As I will show in an upcoming paper, these advant= ages do not stem from the act of propagating large blocks but rather from t= he block subsidies which allow miners to mine unnecessary large blocks irre= gardless of the fees contained therein. One typical example is Peter Todd&#= 39;s suggested attack whereby a miner creates a massive block filled with s= pam transactions that pay himself solely to slow down the rest of the netwo= rk and gain an advantage. Putting aside the increased orphan risk arising f= rom the propagation of such a large block, this attack would never be viabl= e if it weren't for the existence of current block subsidies.

As such, exponential increases to the max blocksize make per= fect sense since the block reward decreases exponentially also. All argumen= ts invoking rates of technological advances (see Gavin's original posts= ) don't mean anything. Rational miners will NOT be incentivized to mine= gargantuan spam filled blocks in the presence of a vanishing block reward.=

I truly hope this matter gets the consideration it deserves.= Particularly with the upcoming scaling workshops.

Dpinna

On Aug 21, 2015 11:35 PM, "Daniele Pinna&qu= ot; <daniele.pinna@gmail.com<= /a>> wrote:

"I ran some simulations, and if blocks take 20 seconds to propagat= e, a
network with a miner that has 30% of the hashing power will get 30.3% of th= e blocks."

Peter_R's analysis of fee markets in the absence of bloc= ksize limits [1] shows that the hashrate advantage of a large miner is a si= de-effect of coinbase subsidization. As the block rewards get smaller, so w= ill large miner advantages. An easy way to think about this is as follows:<= /p>

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 sub= sidies 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 bl= ocks, but it will go against their interest to fill them with spam since th= eir 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 thi= s 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 c= apacity. The sooner block rewards become comparable to block fees, the soon= er 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

--001a113ec3a6043b6b051e3e4a70--