Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D38F4E64 for ; Sun, 30 Aug 2015 02:49:31 +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 8DF90157 for ; Sun, 30 Aug 2015 02:49:30 +0000 (UTC) Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M0Kp7-1YiiNM0KMf-00uVfy; Sun, 30 Aug 2015 04:49:26 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_6612673C-2E22-43D3-9205-0DC9AAA5EAC0" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Peter R In-Reply-To: <55E26B82.2070805@mattcorallo.com> Date: Sat, 29 Aug 2015 19:49:23 -0700 Message-Id: References: <55E21F2E.9000308@mattcorallo.com> <786493BB-2136-4587-A309-B8B1A34ED568@gmx.com> <55E26B82.2070805@mattcorallo.com> To: Matt Corallo X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:AZbixVlsGO0TzLqnO/DgwFyIytrOGGVxL8JPSnn9fMJNLPU2BG7 0jRA70be6o53iSFDjLgr1Mg/Kwpq+wrZFBubdBocBSx+lw7Shix09izCXM9qJvN+k3aq2qE TxKAxotbYjbqHB+sViJH1K7QF4kPmetGx+dAqsOWoydodWPAvotVW3uaywQLdLJbj430g+f Et8FBPXWwfZ6IxnEB326g== X-UI-Out-Filterresults: notjunk:1;V01:K0:ebSmSt0zFtA=:w5x2x3uc+RHQkqN2uIc8YF THhuc/pB1JBr87mAEFP0m/LqmB3U4lgPQqbSWQDn5ZIhg7PoO7FyWNWeyjVysar3h0cZ9lW6+ nw8vdG9D+GBURLW6DqksYnAhv5owMihCfPoWmMfk7hpBGKu9O6unrOGu3dVrzcpHOhwIWbOnu jWheoUyuNM5UezBq5HsZjnfa6UrK9rTA1dOn5hlgOx4Q2mf8IcgnfX60+Jb7XD8fhBG8zbZtS CRssOHX0si91S/NtN08+MrL4p8VkYFDpzaoxf0CMKyTJ06eWoNhRPYhGzxMtT1OV4JTm+caxf kaaayZfnqdKy5XEmNh9cu3hXHCF00DLP17KNLMXLzXQB9cYTDB+GTmsYcTCVjXd0FJtd7hAzZ Sji94JpOp1zm7ZPOgW3xKzSGWtZ2T41TORz9BaLAVBiOCbhEcLG13JHxOXzhNy02ZGJ3TMzV5 kaBFEPTxGNhUE8/AHQaaHVjulBBVl2cVteLcvOliBze9UkHqXgEIi4UPCp3yi91EqVQmaRn70 ycqDQ2K9Z6vlnjrh7z96PFbKNSH6P4exNMmstZsFYo/sEAoD543CvK6rxlKNjCYltAlDKbwij pCJiK8EAje1J8hUiX4yhmpb+yoog0/EEymhYgFrYZXDRoYU0w3WjnbUCcNqD1DinPNaQ7O7vR 4C4gHfflsZjnrUMRvC9CWr4NqlgVoTY2+UQtLLP2KayfZjyiZMbl50uxx0DlJQ62lFVhFNP1v HaXEfDkkIyfB/h8eRd3Q1Lmx7hBxX8pQGto3LA== 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: Sun, 30 Aug 2015 02:49:31 -0000 --Apple-Mail=_6612673C-2E22-43D3-9205-0DC9AAA5EAC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Matt, > It is not a purely academic scenario that blocks contain effectively = no > information (that was not previously relayed). The results of my paper hold unless the information about the included = transactions is identically zero. If this information is extremely = small, then I agree that something other than the orphan cost would = drive the fee market. I don't think this will ever by the case, however. > 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=85. In this paragraph, you are talking about intra-miner communication (you = refer to other nodes "of theirs"). I agree that this can be very fast = because there's only one entity involved.=20 > Thus, the orphan risk for including a transaction is related to the > validation time =85 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. I look forward to hearing your talk about the Relay Network. Let's = image there was no block size limit. Using the Relay Network as it = currently operates now, how big would the block solution announcement = be: (1) if a miner published a 10 MB block where 100% of the transactions = are known by the other nodes? =20 (2) if a miner published a 10 MB block where 90% of the transactions are = known by the other nodes? =20 (3) if a miner published a 100 MB spam block where 0% of the = transactions are known by the other nodes? Best regards, Peter >=20 > Matt >=20 > On 08/29/15 23:17, Peter R wrote: >> Hello Matt and Daniele, >>=20 >>> 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= >>=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 >>=20 >> https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf >>=20 >> 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! >>=20 >> Best regards, >> Peter >>=20 >>=20 >>=20 >> On 2015-08-29, at 2:07 PM, Matt Corallo via bitcoin-dev >> > > wrote: >>=20 >>> 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 >>>> 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 >>=20 --Apple-Mail=_6612673C-2E22-43D3-9205-0DC9AAA5EAC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello = Matt,

It is not a purely academic scenario that blocks contain = effectively no
information (that was not previously relayed). =

The results of my paper hold unless the = information about the included transactions is identically zero. =  If this information is extremely small, then I agree that = something other than the orphan cost would drive the fee market. I don't = think this will ever by the case, however.

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

In this paragraph, you are = talking about intra-miner communication (you refer to other nodes "of = theirs").   I agree that this can be very fast because there's = only one entity involved. 

Thus, = the orphan risk for including a transaction is related to = the
validation time =85 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.

I look forward to = hearing your talk about the Relay Network.  Let's image there was = no block size limit.  Using the Relay Network as it currently = operates now, how big would the block solution announcement = be:

(1) if a miner published a 10 MB block = where 100% of the transactions are known by the other nodes? =  

(2) if a miner published a 10 MB block = where 90% of the transactions are known by the other nodes? =  

(3) if a miner published a 100 MB spam = block where 0% of the transactions are known by the other = nodes?

Best = regards,
Peter



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.li= nuxfoundation.org
<mailto:bitcoin-dev@l= ists.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/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
<mailto:bitcoin-dev@lists.linuxfoundation.org&= gt;
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<= /blockquote>

= --Apple-Mail=_6612673C-2E22-43D3-9205-0DC9AAA5EAC0--