Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FEE72BCD-614C-4124-ABE4-976A07A9A33E"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Peter R <peter_r@gmx.com>
In-Reply-To: <55E21F2E.9000308@mattcorallo.com>
Date: Sat, 29 Aug 2015 16:17:12 -0700
Message-Id: <786493BB-2136-4587-A309-B8B1A34ED568@gmx.com>
References: <CAEgR2PHggX-8r+FZm=pod9KQv3E3=8wo-9nOB02-YDmy5NGsZQ@mail.gmail.com>
	<55E21F2E.9000308@mattcorallo.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
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
Precedence: list


--Apple-Mail=_FEE72BCD-614C-4124-ABE4-976A07A9A33E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hello Matt and Daniele,

>  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

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

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


--Apple-Mail=_FEE72BCD-614C-4124-ABE4-976A07A9A33E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div>Hello Matt and Daniele,</div><br><blockquote =
type=3D"cite">&nbsp;this seems to&nbsp;ignore the effects of transaction =
validation caches and <b>block<br>compression =
protocols.&nbsp;</b></blockquote><div><br></div><div>The effect of block =
compression protocols is included. &nbsp;This is what I call the "coding =
gain" and use the Greek letter "gamma" to =
represent.&nbsp;</div><div><br></div><div>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). =
&nbsp;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. &nbsp;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. =
&nbsp;&nbsp;</div><div><br></div><div>&nbsp;<a =
href=3D"https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf">https:=
//dl.dropboxusercontent.com/u/43331625/feemarket.pdf</a></div><div><br></d=
iv><div>I've exchanged emails with Greg Maxwell about (what IMO is) an =
academic scenario where the block solutions announcements contain <b>no =
information at all</b> about the transactions included in the blocks. =
&nbsp;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). &nbsp;I look forward to a white =
paper demonstrating otherwise!</div><div><br></div><div>Best =
regards,</div><div>Peter</div><div><br></div><div><br></div><br><div><div>=
On 2015-08-29, at 2:07 PM, Matt Corallo via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><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> =
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>https://lists.linuxfoundation.org/mailman/listinf=
o/bitcoin-dev<br></blockquote></div><br></body></html>=

--Apple-Mail=_FEE72BCD-614C-4124-ABE4-976A07A9A33E--