diff options
| author | Peter R <peter_r@gmx.com> | 2015-08-29 16:17:12 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-08-29 23:17:04 +0000 |
| commit | 76a1b8a4cf624129408898544bedcf9f94b29690 (patch) | |
| tree | edfd0cc3a2664cbc3122ae0812f2d1ad9d3e1795 | |
| parent | 96f3c20afaca731cd0318548d3946339dabd7de5 (diff) | |
| download | pi-bitcoindev-76a1b8a4cf624129408898544bedcf9f94b29690.tar.gz pi-bitcoindev-76a1b8a4cf624129408898544bedcf9f94b29690.zip | |
Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped Block Size Fee Markets
| -rw-r--r-- | 4b/3b04fe80050016b8f5ee4f115a41df1fb3b408 | 277 |
1 files changed, 277 insertions, 0 deletions
diff --git a/4b/3b04fe80050016b8f5ee4f115a41df1fb3b408 b/4b/3b04fe80050016b8f5ee4f115a41df1fb3b408 new file mode 100644 index 000000000..42afbb0ed --- /dev/null +++ b/4b/3b04fe80050016b8f5ee4f115a41df1fb3b408 @@ -0,0 +1,277 @@ +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 BDE7B1275 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 29 Aug 2015 23:17:04 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D2BBD15F + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 29 Aug 2015 23:17:03 +0000 (UTC) +Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx102) + with ESMTPSA (Nemesis) id 0LsOsW-1YYavr3U2C-011yWR; + Sun, 30 Aug 2015 01:17:00 +0200 +Content-Type: multipart/alternative; + boundary="Apple-Mail=_FEE72BCD-614C-4124-ABE4-976A07A9A33E" +Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) +From: Peter R <peter_r@gmx.com> +In-Reply-To: <55E21F2E.9000308@mattcorallo.com> +Date: Sat, 29 Aug 2015 16:17:12 -0700 +Message-Id: <786493BB-2136-4587-A309-B8B1A34ED568@gmx.com> +References: <CAEgR2PHggX-8r+FZm=pod9KQv3E3=8wo-9nOB02-YDmy5NGsZQ@mail.gmail.com> + <55E21F2E.9000308@mattcorallo.com> +To: Matt Corallo <lf-lists@mattcorallo.com> +X-Mailer: Apple Mail (2.1510) +X-Provags-ID: V03:K0:Ij9wnPePw8gqtLDuPirLtX2Bstx+bWc+nCeIH1FVPED49r+tgjT + AmeUlFS3dvZoNIhVe9EB2lL12BGxxa8tZgIbX1L++53vwuc90sZHLkamTlviWnnSl0UbHZl + bedGtIKu32jCONOQehujgaIGfvm5qLK4fe+t7GQv+0A0KanCCGKmsYCLB0VinxSD1Qs2Aoa + kouZ2zJHx46uky1fhWe7w== +X-UI-Out-Filterresults: notjunk:1;V01:K0:UxBDs5JGfBs=:P0txK9IoD1tXwx1UA+ZN5i + lc2CupxlRcLVBFw17TpOo7HC7r8AWIXZLv4c6GiLlR6Rqn4PMy3d+j31ddNsEWP2Tx0sVUz43 + 85f42aSCOJ+XTYPmiZfqeJeOuqgb2WX2CBtr/2NJ8xC+oZjtTh8IeoWEZziAoWBhASb5okFca + XVKNoDmZbHUlcYZtrxP3EL5ww0+xGzRrlslnNnIyrZjIc9VOJLe9Gr8lFSWTQLtplPRgKpxcW + ePa5pzGP1FXzpR8Yp0vvg4O4RwEKKSQiCIiTYZCZwP1thLVgDBc8Dz+knhRnGzyPtR4m3jv0d + 2EVd8YLaMS26j5sEgkkh8lGTERoN9uq0M3RPZtqDax7ucfHdiWCb1jFAgaAwGiCjpp37DvIFu + UksXiSg6QLlV2x9ko+eQYnY2StBwvWO9Bn65YSSsJOfpTjLe6r0foygO/E3kfJf9FvMVd+iJS + mN0EONLp+bmoENpcrxy1so2r+BEYSd6bgLbtDN0pvE3l1NSRl5ApKr1M1zTxVSY9vM/iWQCha + hOowQ00F67I5SJ1Bp90fdo+glmj/I73WGmMz0wjR6fT48hzDuMt5yNRZLZVIog1E2o3onYFbK + 92XaW5bQFYixGMq7Ix9BqFBXqtsS0jYmW1KRGjgYqp2tTX1uhuQ2S44NGsDRtozpGEHpbw5lP + iegBGeIuow2A7HamKHzRiU1Jw/O9ymipTRm8xZuhL0IWcH3jyTX2U7XKWgdrjVTLJJoOmPG8n + a09oQ8lMunYoXazg6/MIodG9GKDh5AegufA3sg== +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: Sat, 29 Aug 2015 23:17:04 -0000 + + +--Apple-Mail=_FEE72BCD-614C-4124-ABE4-976A07A9A33E +Content-Transfer-Encoding: quoted-printable +Content-Type: text/plain; + charset=us-ascii + +Hello Matt and Daniele, + +> 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 + +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 + + https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf + +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! + +Best regards, +Peter + + + +On 2015-08-29, at 2:07 PM, Matt Corallo via bitcoin-dev = +<bitcoin-dev@lists.linuxfoundation.org> wrote: + +> 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 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 +>>=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 +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + + +--Apple-Mail=_FEE72BCD-614C-4124-ABE4-976A07A9A33E +Content-Transfer-Encoding: quoted-printable +Content-Type: text/html; + charset=us-ascii + +<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = +charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = +-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = +"><div>Hello Matt and Daniele,</div><br><blockquote = +type=3D"cite"> this seems to ignore the effects of transaction = +validation caches and <b>block<br>compression = +protocols. </b></blockquote><div><br></div><div>The effect of block = +compression protocols is included. This is what I call the "coding = +gain" and use the Greek letter "gamma" to = +represent. </div><div><br></div><div>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. = + </div><div><br></div><div> <a = +href=3D"https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf">https:= +//dl.dropboxusercontent.com/u/43331625/feemarket.pdf</a></div><div><br></d= +iv><div>I've exchanged emails with Greg Maxwell about (what IMO is) an = +academic scenario where the block solutions announcements contain <b>no = +information at all</b> 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!</div><div><br></div><div>Best = +regards,</div><div>Peter</div><div><br></div><div><br></div><br><div><div>= +On 2015-08-29, at 2:07 PM, Matt Corallo via bitcoin-dev <<a = +href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li= +nuxfoundation.org</a>> wrote:</div><br = +class=3D"Apple-interchange-newline"><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> = +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>https://lists.linuxfoundation.org/mailman/listinf= +o/bitcoin-dev<br></blockquote></div><br></body></html>= + +--Apple-Mail=_FEE72BCD-614C-4124-ABE4-976A07A9A33E-- + |