diff options
| author | Daniele Pinna <daniele.pinna@gmail.com> | 2015-08-27 00:22:42 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-26 22:22:44 +0000 |
| commit | 3687e82f104c8b5df368de5c8de6f37495aaf040 (patch) | |
| tree | 671cf4a6be3e478eb9d3a29d712014d99a4f0ca4 | |
| parent | 7dd60d069deda702e51f058888bdcb4436e4bdf5 (diff) | |
| download | pi-bitcoindev-3687e82f104c8b5df368de5c8de6f37495aaf040.tar.gz pi-bitcoindev-3687e82f104c8b5df368de5c8de6f37495aaf040.zip | |
[bitcoin-dev] Unlimited Max Blocksize (reprise)
| -rw-r--r-- | 2e/5dd3e9403bb70c338aa83196c5d5b18e473645 | 201 |
1 files changed, 201 insertions, 0 deletions
diff --git a/2e/5dd3e9403bb70c338aa83196c5d5b18e473645 b/2e/5dd3e9403bb70c338aa83196c5d5b18e473645 new file mode 100644 index 000000000..7b611a465 --- /dev/null +++ b/2e/5dd3e9403bb70c338aa83196c5d5b18e473645 @@ -0,0 +1,201 @@ +Return-Path: <daniele.pinna@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id ADCC9E47 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 26 Aug 2015 22:22:42 +0000 (UTC) +Received: by iodv127 with SMTP id v127so36759432iod.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CAEgR2PHnJfCwMzFCrJr_TnFzRjJ7GVE-4=omva92nO6g9z2LSQ@mail.gmail.com> +References: <CAEgR2PEMueQc7GgYWYMOZgtKHvxHgoe1rT1F+YpG2x0h74+_Gw@mail.gmail.com> + <CAEgR2PHnJfCwMzFCrJr_TnFzRjJ7GVE-4=omva92nO6g9z2LSQ@mail.gmail.com> +Date: Thu, 27 Aug 2015 00:22:42 +0200 +Message-ID: <CAEgR2PHdRGe2Sj+yO_Ng0cCr_89qi_KXaqMKTY6J2Ksz-PWwzA@mail.gmail.com> +From: Daniele Pinna <daniele.pinna@gmail.com> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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" <daniele.pinna@gmail.com> 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 + +<p dir=3D"ltr">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. </p> +<p dir=3D"ltr">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?= + </p> +<p dir=3D"ltr">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.= + </p> +<p dir=3D"ltr">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. </p> +<p dir=3D"ltr">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.= + </p> +<p dir=3D"ltr">I truly hope this matter gets the consideration it deserves.= + Particularly with the upcoming scaling workshops. </p> +<p dir=3D"ltr">Dpinna</p> +<div class=3D"gmail_quote">On Aug 21, 2015 11:35 PM, "Daniele Pinna&qu= +ot; <<a href=3D"mailto:daniele.pinna@gmail.com">daniele.pinna@gmail.com<= +/a>> wrote:<br type=3D"attribution"><blockquote class=3D"quote" style=3D= +"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"l= +tr">"I ran some simulations, and if blocks take 20 seconds to propagat= +e, a<br> +network with a miner that has 30% of the hashing power will get 30.3% of th= +e blocks."</p> +<p dir=3D"ltr">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> +<p dir=3D"ltr">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. </p> +<p dir=3D"ltr">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. </p> +<p dir=3D"ltr">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. </p> +<p dir=3D"ltr">Dpinna</p> +<p dir=3D"ltr">[1] <a href=3D"http://www.scribd.com/mobile/doc/273443462/A-= +Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit" target=3D"_blank"= +>http://www.scribd.com/mobile/doc/273443462/A-Transaction-Fee-Market-Exists= +-Without-a-Block-Size-Limit</a></p> +</blockquote></div> + +--001a113ec3a6043b6b051e3e4a70-- + |