> 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 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 >>> >> > 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/276849939/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.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>> >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>