MIME-Version: 1.0
From: Daniele Pinna <daniele.pinna@gmail.com>
Date: Sat, 29 Aug 2015 18:43:23 +0200
Message-ID: <CAEgR2PHggX-8r+FZm=pod9KQv3E3=8wo-9nOB02-YDmy5NGsZQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=089e013d116e3b3ca1051e75e783
Subject: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped Block
	Size Fee Markets
Precedence: list

--089e013d116e3b3ca1051e75e783
Content-Type: text/plain; charset=UTF-8

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

--089e013d116e3b3ca1051e75e783
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I&#39;d like to submit this paper to the dev-list whi=
ch 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&#39;s work left off correcting a mistake and addressing the c=
ritiques made by the community to his work.</div><div><br>The main result o=
f the work is a detailed analysis of mining advantages (defined as the adde=
d profit per unit of hash) as a function of miner hashrate. In it, I show h=
ow large block subsidies (or better, low mempool fees-to-subsidy ratios) in=
centivize the pooling of large hashrates due to the steady increasing of ma=
rginal profits as hashrates grow.=C2=A0</div><div><br></div><div>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 w=
hich has access to expected profits an order of magnitude larger than every=
one else. As block subsidies decrease, this high-efficiency class is expect=
ed to vanish leading to a marginal profit structure which decreases as a fu=
nction of hashrate.</div><div><br></div><div>This work has vacuumed my enti=
re 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 b=
lock size scaling proposal (BIP101) which, due to the XT fork drama, I beli=
eve has been placed hastily and undeservedly on the chopping block.</div><d=
iv><br></div><a href=3D"https://www.scribd.com/doc/276849939/On-the-Nature-=
of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets">https://www.scribd.=
com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-=
Fee-Markets</a>
<div><br></div><div>Regards,</div><div>Daniele</div></div>

--089e013d116e3b3ca1051e75e783--