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

Thus, the orphan risk for including a transaction is related to the
validation time … 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@lists.linuxfoundation.org
<mailto: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
<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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
<mailto:bitcoin-dev@lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev