Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BDE7B1275 for ; 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 ; 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 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: <55E21F2E.9000308@mattcorallo.com> To: Matt Corallo 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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  this seems to ignore the effects of transaction = validation caches and block
compression = protocols. 

The effect of block = compression protocols is included.  This is what I call the "coding = gain" and use the Greek letter "gamma" to = represent. 

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. =   


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.li= nuxfoundation.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.

Matt

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.

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.

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.

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.

https://www.scribd.com/doc/276849= 939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets


Regards,
Daniele


_____________________________= __________________
bitcoin-dev mailing = list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfounda= tion.org/mailman/listinfo/bitcoin-dev

________________= _______________________________
bitcoin-dev mailing list
bitcoin-dev@lists.li= nuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinf= o/bitcoin-dev

= --Apple-Mail=_FEE72BCD-614C-4124-ABE4-976A07A9A33E--