[bitcoin-dev] On the Nature of Miner Advantages in Uncapped Block Size Fee Markets

Sun Aug 30 03:08:32 UTC 2015

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

Peter  

On 2015-08-29, at 7:35 PM, Matt Corallo <lf-lists at 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).
> 
> Matt
> 
> 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.
>> 
>> 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.
>> 
>> Matt
>> 
>> On 08/29/15 23:17, Peter R wrote:
>>> Hello Matt and Daniele,
>>> 
>>>> 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.   
>>> 
>>> 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 at lists.linuxfoundation.org
>>> <mailto:bitcoin-dev at 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
>>>> <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.
>>>> 
>>>> 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/276849939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> Daniele
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>> 
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> 
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150829/bd748269/attachment.html>