diff options
| author | Peter R <peter_r@gmx.com> | 2015-08-29 20:08:32 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-30 03:08:41 +0000 |
| commit | 84c5d320bb7aa749710890f6f59c73fc6bdfb07b (patch) | |
| tree | f2a732f6e61e1f83ce4ca78c97bde7efb373558f | |
| parent | 6b9fa5b415b3954b888c25acd611267c3cf4dc7a (diff) | |
| download | pi-bitcoindev-84c5d320bb7aa749710890f6f59c73fc6bdfb07b.tar.gz pi-bitcoindev-84c5d320bb7aa749710890f6f59c73fc6bdfb07b.zip | |
Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped Block Size Fee Markets
| -rw-r--r-- | 7c/9c00bac027eea2ecbf5ffc4fb7b073af3ab787 | 429 |
1 files changed, 429 insertions, 0 deletions
diff --git a/7c/9c00bac027eea2ecbf5ffc4fb7b073af3ab787 b/7c/9c00bac027eea2ecbf5ffc4fb7b073af3ab787 new file mode 100644 index 000000000..8287a8b88 --- /dev/null +++ b/7c/9c00bac027eea2ecbf5ffc4fb7b073af3ab787 @@ -0,0 +1,429 @@ +Return-Path: <peter_r@gmx.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 3B6D3107C + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 30 Aug 2015 03:08:41 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9832A17D + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 30 Aug 2015 03:08:39 +0000 (UTC) +Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx101) + with ESMTPSA (Nemesis) id 0LoJDJ-1Z3gpn0uuf-00gG4B; + Sun, 30 Aug 2015 05:08:35 +0200 +Content-Type: multipart/alternative; + boundary="Apple-Mail=_98028B39-A9FC-4DC8-80A8-17F1FAA1DACA" +Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) +From: Peter R <peter_r@gmx.com> +In-Reply-To: <55E26BDE.2080607@mattcorallo.com> +Date: Sat, 29 Aug 2015 20:08:32 -0700 +Message-Id: <DCEBB396-0FBD-40B0-95F5-F9936F580E2A@gmx.com> +References: <CAEgR2PHggX-8r+FZm=pod9KQv3E3=8wo-9nOB02-YDmy5NGsZQ@mail.gmail.com> + <55E21F2E.9000308@mattcorallo.com> + <786493BB-2136-4587-A309-B8B1A34ED568@gmx.com> + <55E26B82.2070805@mattcorallo.com> + <55E26BDE.2080607@mattcorallo.com> +To: Matt Corallo <lf-lists@mattcorallo.com> +X-Mailer: Apple Mail (2.1510) +X-Provags-ID: V03:K0:oA8R5tQ9PV2oLo4SdDWpu6CP+ZWrGVL/50URZbmbnALoz67x/e1 + I0YH4sdV/gn5I3pxqNduLrpDipJhg6w2PT2yLHz2nUeQfb9PmnnXYWO9kHcJHqu/p5F/vmr + cjiu0mwte+EOt9zE+0m89D7q3PcBmkmXV40beEHxV+n7F9pYyt9Z7Vcn7tKO3KZga1UN4tk + DlAU5DxNwaWtYpwfxkoJg== +X-UI-Out-Filterresults: notjunk:1;V01:K0:ngMycWM9luk=:u08oMLNvZjKhoUtwYDONtq + o/uaoOTlJmQstX/bBHknmJ0sY73qTBAuXsi/m1PVM10mrq1Q1jEGbBdniF5ZvQm9V/Uja5q4f + F82+AB3atn0+b6kmWVK+axxcq3l9DeoOqMlUdYfGw2ZRvCs/6380D7UOWtYc5U6ePSHAVEoTq + Kc31MSL7D2umbZOfJTnqskc7l27SWNdWRF9A+FK/Ki0gAviNteJnapmWfxSaF3aR2caF5jpmM + /WPefzT89aMf6gNUyDuF2Ku4CJoWkLlgODcqKwdRP3vEfwEW+ikh1282fS4zbXLmjPSiVMZxX + 2+RfPduLnrH2dRCm4bJbIiiFeLVAAziyjvGlS1FGQVU3QthAHWGLJLRE5HX9oUq/uj76BjvK2 + BOPyJUKJSoLQxDG/wFU2lndkBRzi510F4SEdoSyxkjKNfS2iWtk7UgZ8CzoGxFgJZfagxhDic + R41eZDa9WwFTVaQ32H5qnY+r9rBLcHHO/Ugr7V8EPiUuSD7C30e6mqbAMw0dVN9ZJjsM2V1Lc + T+tIAAJ14AwDKCDbOJKjCfOTqsbiiCIBicPUTyjLVTHg+TBY6FCrwIispRfPaBdPDwQgTGiGO + 99KPHodP0Dy5an8rpTN/0RWNMNDp+ihYJEXw/zBKz+l2ueK09E8d0T7jwNOgRXkZuf7poNGrQ + Pxx3W01y0d/uFGqd8IBzoShKxRyYAeRbQKVeejkK4h66qOs0yzgMXnlCynRlRqOQYQiCvWT+Z + xg3SU363j+Yv8n6MrPO9Kbkgc4VaM9h+dVeHbA== +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 +Cc: bitcoin-dev@lists.linuxfoundation.org, + Daniele Pinna <daniele.pinna@gmail.com> +Subject: Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped + Block Size Fee Markets +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: Sun, 30 Aug 2015 03:08:41 -0000 + + +--Apple-Mail=_98028B39-A9FC-4DC8-80A8-17F1FAA1DACA +Content-Transfer-Encoding: quoted-printable +Content-Type: text/plain; + charset=windows-1252 + +> Of course this assumes the network does not change any as a result of +> such a system. But such a system provides strong incentives for the +> network to centralize in other ways (put all the mining nodes in one = +DC +> for all miners, etc). + +If all the mining nodes are in one data center, and if all the nodes are = +programmed to build blocks in essentially the same way, then I would = +agree that the orphan cost would be negligible! I will add this as an = +example of a network configuration where the results of my paper would = +be less relevant. =20 + +Peter =20 + + +On 2015-08-29, at 7:35 PM, Matt Corallo <lf-lists@mattcorallo.com> = +wrote: + +> Of course this assumes the network does not change any as a result of +> such a system. But such a system provides strong incentives for the +> network to centralize in other ways (put all the mining nodes in one = +DC +> for all miners, etc). +>=20 +> Matt +>=20 +> On 08/30/15 02:33, Matt Corallo via bitcoin-dev wrote: +>> It is not a purely academic scenario that blocks contain effectively = +no +>> information (that was not previously relayed). I'm not aware of any +>> public code to do so, but I know several large miners who pre-relay = +the +>> block(s) they are working on to other nodes of theirs around the = +globe. +>> This means at announce-time you have only a few bytes to broadcast = +(way +>> less than a packet, and effects of using smaller packets to relay = +things +>> vs larger packets are very small, if anything). After you've = +broadcast +>> to all of your nodes, hops to other mining nodes are probably only a +>> handful of ms away with very low packet loss, so relay time is no = +longer +>> connected to transaction inclusion at all (unless you're talking = +about +>> multi-GB blocks). Of course, this is relay time for large miners who = +can +>> invest time and money to build such systems. Small miners are = +completely +>> screwed in such a system. +>>=20 +>> Thus, the orphan risk for including a transaction is related to the +>> validation time (which is only DB modify-utxo-set time, essentially, +>> which maybe you can optimize much of that away, too, and only have to +>> pass over mempool or so). Anyway, my point, really, is that though +>> miners will have an incentive to not include transactions which will +>> trigger validation by other nodes (ie things not already in their +>> mempool), the incentive to not include transactions which have = +already +>> been relayed around sufficiently is, while not theoretically zero, as +>> near to zero in practice as you can get. +>>=20 +>> Matt +>>=20 +>> On 08/29/15 23:17, Peter R wrote: +>>> Hello Matt and Daniele, +>>>=20 +>>>> this seems to ignore the effects of transaction validation caches = +and +>>>> *block +>>>> compression protocols. * +>>>=20 +>>> The effect of block compression protocols is included. This is what = +I +>>> call the "coding gain" and use the Greek letter "gamma" to = +represent.=20 +>>>=20 +>>> As long as the block solution announcements contain information = +(i.e., +>>> Shannon Entropy) about the transactions included in a block, then = +the +>>> fee market will be "healthy" according to the definitions given in = +the +>>> linked paper (see below). This is the case right now, this is the = +case +>>> with your relay network, and this would be the case using any +>>> implementation of IBLTs that I can imagine, so long as miners can = +still +>>> construct blocks according to their own volition. The "healthy fee +>>> market" result follows from the Shannon-Hartley theorem; the = +SH-theorem +>>> describes the maximum rate at which information (Shannon Entropy) = +can be +>>> transmitted over a physical communication channel. =20 +>>>=20 +>>> https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf +>>>=20 +>>> I've exchanged emails with Greg Maxwell about (what IMO is) an = +academic +>>> scenario where the block solutions announcements contain *no = +information +>>> at all* about the transactions included in the blocks. Although the = +fee +>>> market would not be healthy in such a scenario, it is my feeling = +that +>>> this also requires miners to relinquish their ability to construct +>>> blocks according to their own volition (i.e., the system would = +already +>>> be centralized). I look forward to a white paper demonstrating = +otherwise! +>>>=20 +>>> Best regards, +>>> Peter +>>>=20 +>>>=20 +>>>=20 +>>> On 2015-08-29, at 2:07 PM, Matt Corallo via bitcoin-dev +>>> <bitcoin-dev@lists.linuxfoundation.org +>>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: +>>>=20 +>>>> I believe it was pointed out previously in the discussion of the = +Peter R +>>>> paper, but I'll repeat it here so that its visible - this seems to +>>>> ignore the effects of transaction validation caches and block +>>>> compression protocols. Many large miners already have their own = +network +>>>> to relay blocks around the globe with only a few bytes on the wire = +at +>>>> block-time, and there is also the bitcoinrelaynetwork.org +>>>> <http://bitcoinrelaynetwork.org> network, which +>>>> does the same for smaller miners, albeit with slightly less = +efficiency. +>>>> Also, transaction validation time upon receiving a block can be = +rather +>>>> easily made negligible (ie the only validation time you should have = +is +>>>> the DB modify-utxo-set time). Thus, the increased orphan risk for +>>>> including a transaction can be reduced to a very, very tiny amount, +>>>> making the optimal blocksize, essentially, including everything = +that +>>>> you're confident is in the mempool of other reasonably large = +miners. +>>>>=20 +>>>> Matt +>>>>=20 +>>>> On 08/29/15 16:43, Daniele Pinna via bitcoin-dev wrote: +>>>>> I'd like to submit this paper to the dev-list which analyzes how = +miner +>>>>> advantages scale with network and mempool properties in a scenario = +of +>>>>> uncapped block sizes. The work proceeds, in a sense, from where = +Peter +>>>>> R's work left off correcting a mistake and addressing the = +critiques made +>>>>> by the community to his work. +>>>>>=20 +>>>>> The main result of the work is a detailed analysis of mining = +advantages +>>>>> (defined as the added profit per unit of hash) as a function of = +miner +>>>>> hashrate. In it, I show how large block subsidies (or better, low +>>>>> mempool fees-to-subsidy ratios) incentivize the pooling of large +>>>>> hashrates due to the steady increasing of marginal profits as = +hashrates +>>>>> grow. +>>>>>=20 +>>>>> The paper also shows that part of the large advantage the large = +miners +>>>>> have today is due to there being a barrier to entry into a +>>>>> high-efficiency mining class which has access to expected profits = +an +>>>>> order of magnitude larger than everyone else. As block subsidies +>>>>> decrease, this high-efficiency class is expected to vanish leading = +to a +>>>>> marginal profit structure which decreases as a function of = +hashrate. +>>>>>=20 +>>>>> This work has vacuumed my entire life for the past two weeks = +leading me +>>>>> to lag behind on a lot of work. I apologize for typos which I may = +not +>>>>> have seen. I stand by for any comments the community may have and = +look +>>>>> forward to reigniting consideration of a block size scaling = +proposal +>>>>> (BIP101) which, due to the XT fork drama, I believe has been = +placed +>>>>> hastily and undeservedly on the chopping block. +>>>>>=20 +>>>>> = +https://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-= +Uncapped-Block-Size-Fee-Markets +>>>>>=20 +>>>>>=20 +>>>>> Regards, +>>>>> Daniele +>>>>>=20 +>>>>>=20 +>>>>> _______________________________________________ +>>>>> bitcoin-dev mailing list +>>>>> bitcoin-dev@lists.linuxfoundation.org +>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>>>>>=20 +>>>> _______________________________________________ +>>>> bitcoin-dev mailing list +>>>> bitcoin-dev@lists.linuxfoundation.org +>>>> <mailto:bitcoin-dev@lists.linuxfoundation.org> +>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>>>=20 +>> _______________________________________________ +>> bitcoin-dev mailing list +>> bitcoin-dev@lists.linuxfoundation.org +>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>>=20 + + +--Apple-Mail=_98028B39-A9FC-4DC8-80A8-17F1FAA1DACA +Content-Transfer-Encoding: quoted-printable +Content-Type: text/html; + charset=windows-1252 + +<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = +charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; = +-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = +"><div><blockquote type=3D"cite">Of course this assumes the network does = +not change any as a result of<br>such a system. But such a system = +provides strong incentives for the<br>network to centralize in other = +ways (<b>put all the mining nodes in one DC<br>for all miners, = +etc</b>).</blockquote><br></div><div>If all the mining nodes are in one = +data center, and if all the nodes are programmed to build blocks in = +essentially the same way, then I would agree that the orphan cost would = +be negligible! I will add this as an example of a network = +configuration where the results of my paper would be less relevant. = + </div><div><br></div><div>Peter = + </div><div><br></div><br><div><div>On 2015-08-29, at 7:35 PM, Matt = +Corallo <<a = +href=3D"mailto:lf-lists@mattcorallo.com">lf-lists@mattcorallo.com</a>> = +wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = +type=3D"cite">Of course this assumes the network does not change any as = +a result of<br>such a system. But such a system provides strong = +incentives for the<br>network to centralize in other ways (put all the = +mining nodes in one DC<br>for all miners, etc).<br><br>Matt<br><br>On = +08/30/15 02:33, Matt Corallo via bitcoin-dev wrote:<br><blockquote = +type=3D"cite">It is not a purely academic scenario that blocks contain = +effectively no<br>information (that was not previously relayed). I'm not = +aware of any<br>public code to do so, but I know several large miners = +who pre-relay the<br>block(s) they are working on to other nodes of = +theirs around the globe.<br>This means at announce-time you have only a = +few bytes to broadcast (way<br>less than a packet, and effects of using = +smaller packets to relay things<br>vs larger packets are very small, if = +anything). After you've broadcast<br>to all of your nodes, hops to other = +mining nodes are probably only a<br>handful of ms away with very low = +packet loss, so relay time is no longer<br>connected to transaction = +inclusion at all (unless you're talking about<br>multi-GB blocks). Of = +course, this is relay time for large miners who can<br>invest time and = +money to build such systems. Small miners are completely<br>screwed in = +such a system.<br><br>Thus, the orphan risk for including a transaction = +is related to the<br>validation time (which is only DB modify-utxo-set = +time, essentially,<br>which maybe you can optimize much of that away, = +too, and only have to<br>pass over mempool or so). Anyway, my point, = +really, is that though<br>miners will have an incentive to not include = +transactions which will<br>trigger validation by other nodes (ie things = +not already in their<br>mempool), the incentive to not include = +transactions which have already<br>been relayed around sufficiently is, = +while not theoretically zero, as<br>near to zero in practice as you can = +get.<br><br>Matt<br><br>On 08/29/15 23:17, Peter R wrote:<br><blockquote = +type=3D"cite">Hello Matt and Daniele,<br><br><blockquote type=3D"cite"> = +this seems to ignore the effects of transaction validation caches = +and<br>*block<br>compression protocols. *<br></blockquote><br>The effect = +of block compression protocols is included. This is what I<br>call = +the "coding gain" and use the Greek letter "gamma" to represent. = +<br><br>As long as the block solution announcements contain information = +(i.e.,<br>Shannon Entropy) about the transactions included in a block, = +then the<br>fee market will be "healthy" according to the definitions = +given in the<br>linked paper (see below). This is the case right = +now, this is the case<br>with your relay network, and this would be the = +case using any<br>implementation of IBLTs that I can imagine, so long as = +miners can still<br>construct blocks according to their own volition. = + The "healthy fee<br>market" result follows from the = +Shannon-Hartley theorem; the SH-theorem<br>describes the maximum rate at = +which information (Shannon Entropy) can be<br>transmitted over a = +physical communication channel. <br><br> <a = +href=3D"https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf">https:= +//dl.dropboxusercontent.com/u/43331625/feemarket.pdf</a><br><br>I've = +exchanged emails with Greg Maxwell about (what IMO is) an = +academic<br>scenario where the block solutions announcements contain *no = +information<br>at all* about the transactions included in the blocks. = + Although the fee<br>market would not be healthy in such a = +scenario, it is my feeling that<br>this also requires miners to = +relinquish their ability to construct<br>blocks according to their own = +volition (i.e., the system would already<br>be centralized). I = +look forward to a white paper demonstrating otherwise!<br><br>Best = +regards,<br>Peter<br><br><br><br>On 2015-08-29, at 2:07 PM, Matt Corallo = +via bitcoin-dev<br><<a = +href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li= +nuxfoundation.org</a><br><<a = +href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">mailto:bitcoin-dev@l= +ists.linuxfoundation.org</a>>> wrote:<br><br><blockquote = +type=3D"cite">I believe it was pointed out previously in the discussion = +of the Peter R<br>paper, but I'll repeat it here so that its visible - = +this seems to<br>ignore the effects of transaction validation caches and = +block<br>compression protocols. Many large miners already have their own = +network<br>to relay blocks around the globe with only a few bytes on the = +wire at<br>block-time, and there is also the <a = +href=3D"http://bitcoinrelaynetwork.org">bitcoinrelaynetwork.org</a><br><= +;<a = +href=3D"http://bitcoinrelaynetwork.org">http://bitcoinrelaynetwork.org</a>= +> network, which<br>does the same for smaller miners, albeit with = +slightly less efficiency.<br>Also, transaction validation time upon = +receiving a block can be rather<br>easily made negligible (ie the only = +validation time you should have is<br>the DB modify-utxo-set time). = +Thus, the increased orphan risk for<br>including a transaction can be = +reduced to a very, very tiny amount,<br>making the optimal blocksize, = +essentially, including everything that<br>you're confident is in the = +mempool of other reasonably large miners.<br><br>Matt<br><br>On 08/29/15 = +16:43, Daniele Pinna via bitcoin-dev wrote:<br><blockquote = +type=3D"cite">I'd like to submit this paper to the dev-list which = +analyzes how miner<br>advantages scale with network and mempool = +properties in a scenario of<br>uncapped block sizes. The work proceeds, = +in a sense, from where Peter<br>R's work left off correcting a mistake = +and addressing the critiques made<br>by the community to his = +work.<br><br>The main result of the work is a detailed analysis of = +mining advantages<br>(defined as the added profit per unit of hash) as a = +function of miner<br>hashrate. In it, I show how large block subsidies = +(or better, low<br>mempool fees-to-subsidy ratios) incentivize the = +pooling of large<br>hashrates due to the steady increasing of marginal = +profits as hashrates<br>grow.<br><br>The paper also shows that part of = +the large advantage the large miners<br>have today is due to there being = +a barrier to entry into a<br>high-efficiency mining class which has = +access to expected profits an<br>order of magnitude larger than everyone = +else. As block subsidies<br>decrease, this high-efficiency class is = +expected to vanish leading to a<br>marginal profit structure which = +decreases as a function of hashrate.<br><br>This work has vacuumed my = +entire life for the past two weeks leading me<br>to lag behind on a lot = +of work. I apologize for typos which I may not<br>have seen. I stand by = +for any comments the community may have and look<br>forward to = +reigniting consideration of a block size scaling proposal<br>(BIP101) = +which, due to the XT fork drama, I believe has been placed<br>hastily = +and undeservedly on the chopping block.<br><br><a = +href=3D"https://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advant= +ages-in-Uncapped-Block-Size-Fee-Markets">https://www.scribd.com/doc/276849= +939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets</= +a><br><br><br>Regards,<br>Daniele<br><br><br>_____________________________= +__________________<br>bitcoin-dev mailing = +list<br>bitcoin-dev@lists.linuxfoundation.org<br>https://lists.linuxfounda= +tion.org/mailman/listinfo/bitcoin-dev<br><br></blockquote>________________= +_______________________________<br>bitcoin-dev mailing list<br><a = +href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li= +nuxfoundation.org</a><br><mailto:bitcoin-dev@lists.linuxfoundation.org&= +gt;<br>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<br><= +/blockquote><br></blockquote>_____________________________________________= +__<br>bitcoin-dev mailing list<br><a = +href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li= +nuxfoundation.org</a><br>https://lists.linuxfoundation.org/mailman/listinf= +o/bitcoin-dev<br><br></blockquote></blockquote></div><br></body></html>= + +--Apple-Mail=_98028B39-A9FC-4DC8-80A8-17F1FAA1DACA-- + |