path: root/76/9b610835cd5f63a133e9653a1cd1854d91e979

Return-Path: <peter_r@gmx.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D38F4E64
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <peter_r@gmx.com>
In-Reply-To: <55E26B82.2070805@mattcorallo.com>
Date: Sat, 29 Aug 2015 19:49:23 -0700
Message-Id: <BEB12E85-F4F1-4353-BC78-392119AC7B2E@gmx.com>
References: <CAEgR2PHggX-8r+FZm=pod9KQv3E3=8wo-9nOB02-YDmy5NGsZQ@mail.gmail.com>
	<55E21F2E.9000308@mattcorallo.com>
	<786493BB-2136-4587-A309-B8B1A34ED568@gmx.com>
	<55E26B82.2070805@mattcorallo.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
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 <daniele.pinna@gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
>> <bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> 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
>>> <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.
>>>=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
>>> <mailto: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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hello =
Matt,<div><div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">It is not a purely academic scenario that blocks contain =
<b>effectively</b> no<br>information (that was not previously relayed). =
</blockquote><div><br></div><div>The results of my paper hold unless the =
information about the included transactions is <b>identically zero</b>. =
&nbsp;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.</div><br><blockquote =
type=3D"cite">I'm not aware of any<br>public code to do so, but I know =
several large miners who pre-relay the<br>block(s) they are working on =
to other nodes <b>of theirs</b> around the =
globe=85.<br></blockquote><div><br></div><div>In this paragraph, you are =
talking about intra-miner communication (you refer to other nodes "of =
theirs"). &nbsp;&nbsp;I agree that this can be very fast because there's =
only one entity involved.&nbsp;</div><br><blockquote type=3D"cite">Thus, =
the orphan risk for including a transaction is related to =
the<br>validation time =85&nbsp;the incentive to not include =
transactions which have already<br>been relayed around sufficiently is, =
while not theoretically zero, <b>as<br>near to zero in practice as you =
can get</b>.<br></blockquote><div><br></div><div>I look forward to =
hearing your talk about the Relay Network. &nbsp;Let's image there was =
no block size limit. &nbsp;Using the Relay Network<b> as it currently =
operates now</b>, how big would the block solution announcement =
be:</div><div><br></div><div>(1) if a miner published a 10 MB block =
where 100% of the transactions are known by the other nodes? =
&nbsp;</div><div><br></div><div>(2) if a miner published a 10 MB block =
where 90% of the transactions are known by the other nodes? =
&nbsp;</div><div><br></div><div>(3) if a miner published a 100 MB spam =
block where 0% of the transactions are known by the other =
nodes?</div><div><br></div><div>Best =
regards,</div><div>Peter</div><div><br></div><br><blockquote =
type=3D"cite"><br>Matt<br><br>On 08/29/15 23:17, Peter R =
wrote:<br><blockquote type=3D"cite">Hello Matt and =
Daniele,<br><br><blockquote type=3D"cite"> this seems to ignore the =
effects of transaction validation caches and<br>*block<br>compression =
protocols. *<br></blockquote><br>The effect of block compression =
protocols is included. &nbsp;This is what I<br>call the "coding gain" =
and use the Greek letter "gamma" to represent. <br><br>As long as the =
block solution announcements contain information (i.e.,<br>Shannon =
Entropy) about the transactions included in a block, then the<br>fee =
market will be "healthy" according to the definitions given in =
the<br>linked paper (see below). &nbsp;This is the case right now, this =
is the case<br>with your relay network, and this would be the case using =
any<br>implementation of IBLTs that I can imagine, so long as miners can =
still<br>construct blocks according to their own volition. &nbsp;The =
"healthy fee<br>market" result follows from the Shannon-Hartley theorem; =
the SH-theorem<br>describes the maximum rate at which information =
(Shannon Entropy) can be<br>transmitted over a physical communication =
channel. &nbsp;&nbsp;<br><br> <a =
href=3D"https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf">https:=
//dl.dropboxusercontent.com/u/43331625/feemarket.pdf</a><br><br>I've =
exchanged emails with Greg Maxwell about (what IMO is) an =
academic<br>scenario where the block solutions announcements contain *no =
information<br>at all* about the transactions included in the blocks. =
&nbsp;Although the fee<br>market would not be healthy in such a =
scenario, it is my feeling that<br>this also requires miners to =
relinquish their ability to construct<br>blocks according to their own =
volition (i.e., the system would already<br>be centralized). &nbsp;I =
look forward to a white paper demonstrating otherwise!<br><br>Best =
regards,<br>Peter<br><br><br><br>On 2015-08-29, at 2:07 PM, Matt Corallo =
via bitcoin-dev<br>&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a><br>&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">mailto:bitcoin-dev@l=
ists.linuxfoundation.org</a>&gt;&gt; wrote:<br><br><blockquote =
type=3D"cite">I believe it was pointed out previously in the discussion =
of the Peter R<br>paper, but I'll repeat it here so that its visible - =
this seems to<br>ignore the effects of transaction validation caches and =
block<br>compression protocols. Many large miners already have their own =
network<br>to relay blocks around the globe with only a few bytes on the =
wire at<br>block-time, and there is also the <a =
href=3D"http://bitcoinrelaynetwork.org">bitcoinrelaynetwork.org</a><br>&lt=
;<a =
href=3D"http://bitcoinrelaynetwork.org">http://bitcoinrelaynetwork.org</a>=
&gt; network, which<br>does the same for smaller miners, albeit with =
slightly less efficiency.<br>Also, transaction validation time upon =
receiving a block can be rather<br>easily made negligible (ie the only =
validation time you should have is<br>the DB modify-utxo-set time). =
Thus, the increased orphan risk for<br>including a transaction can be =
reduced to a very, very tiny amount,<br>making the optimal blocksize, =
essentially, including everything that<br>you're confident is in the =
mempool of other reasonably large miners.<br><br>Matt<br><br>On 08/29/15 =
16:43, Daniele Pinna via bitcoin-dev wrote:<br><blockquote =
type=3D"cite">I'd like to submit this paper to the dev-list which =
analyzes how miner<br>advantages scale with network and mempool =
properties in a scenario of<br>uncapped block sizes. The work proceeds, =
in a sense, from where Peter<br>R's work left off correcting a mistake =
and addressing the critiques made<br>by the community to his =
work.<br><br>The main result of the work is a detailed analysis of =
mining advantages<br>(defined as the added profit per unit of hash) as a =
function of miner<br>hashrate. In it, I show how large block subsidies =
(or better, low<br>mempool fees-to-subsidy ratios) incentivize the =
pooling of large<br>hashrates due to the steady increasing of marginal =
profits as hashrates<br>grow.<br><br>The paper also shows that part of =
the large advantage the large miners<br>have today is due to there being =
a barrier to entry into a<br>high-efficiency mining class which has =
access to expected profits an<br>order of magnitude larger than everyone =
else. As block subsidies<br>decrease, this high-efficiency class is =
expected to vanish leading to a<br>marginal profit structure which =
decreases as a function of hashrate.<br><br>This work has vacuumed my =
entire life for the past two weeks leading me<br>to lag behind on a lot =
of work. I apologize for typos which I may not<br>have seen. I stand by =
for any comments the community may have and look<br>forward to =
reigniting consideration of a block size scaling proposal<br>(BIP101) =
which, due to the XT fork drama, I believe has been placed<br>hastily =
and undeservedly on the chopping block.<br><br><a =
href=3D"https://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advant=
ages-in-Uncapped-Block-Size-Fee-Markets">https://www.scribd.com/doc/276849=
939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets</=
a><br><br><br>Regards,<br>Daniele<br><br><br>_____________________________=
__________________<br>bitcoin-dev mailing =
list<br>bitcoin-dev@lists.linuxfoundation.org<br>https://lists.linuxfounda=
tion.org/mailman/listinfo/bitcoin-dev<br><br></blockquote>________________=
_______________________________<br>bitcoin-dev mailing list<br><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a><br>&lt;mailto:bitcoin-dev@lists.linuxfoundation.org&=
gt;<br>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<br><=
/blockquote><br></blockquote></blockquote></div><br></div></body></html>=

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