[bitcoin-dev] ERRATA CORRIGE + Short Theorem

[bitcoin-dev] ERRATA CORRIGE + Short Theorem

[Daniele Pinna]

[-- Attachment #1: Type: text/plain, Size: 2151 bytes --]

Since my longer post seems to be caught in moderator purgatory I will
rehash its results into this much smaller message. I apologize for the
spamming.

I present a theorem whose thesis is obvious to many.

*THESIS: All hashrates* *h' > h generate a revenue per unit of hash v' >
v. *

Let us absurdly[1] assume that an optimal hashrate *h* exists where the
average revenue for each hash in service is maximized. This will result
from perpetually mining blocks of size *q,* is *v. *All larger hashrates *h'
> h* will generate an average revenue per hash *v' < v*(effectively the
conclusion of my paper) due to the higher orphan risk carried from having
to mine blocks of size *q' > q*. Leading from Peter's model and my
analysis, the origin of this balance lies in the fact that larger miners
must somehow be forced to mine larger blocks which in turn carry a larger
orphan risk.

What happens if a large miner *h'* chooses not to mine his optimal block
size *q' *in favor of a seemingly "sub-optimal" block size* q*?
Since he mines a block of identical size as the smaller miner, they will
both carry identical orphan risks[2], and win identical
amounts*R+M(q)* whenever
they successfully mine a block. Since the larger miner can statistically
expect to win *h'/h* more blocks than the smaller miner, they will each
earn an identical revenue per unit of hash *R+M(q)/h*.

This however directly contradicts the assumption that an optimal hashrate
exists beyond which the revenue per unit of hash *v' < v*if  *h' > h. *
*Q.E.D *

This theorem in turn implies the following corollary:

*COROLLARY: **The marginal profit curve is a monotonically increasing of
miner hashrate.*

This simple theorem, suggested implicitly by Gmaxwell disproves any and all
conclusions of my work. Most importantly, centralization pressures will
always be present.

Furthermore,

[1] https://en.wikipedia.org/wiki/Reductio_ad_absurdum
[2] Orphan risks will actually favor the larger hashrate miner leading to
greater revenues per unit of hash.

I thank the dev-list for its valuable time and exchange on the subject
matter. I stand by for any further comments and questions.

[-- Attachment #2: Type: text/html, Size: 5261 bytes --]

Re: [bitcoin-dev] ERRATA CORRIGE + Short Theorem

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2405 bytes --]

On Sun, Aug 30, 2015 at 10:01:00PM +0200, Daniele Pinna via bitcoin-dev wrote:
> Since my longer post seems to be caught in moderator purgatory I will
> rehash its results into this much smaller message. I apologize for the
> spamming.
> 
> I present a theorem whose thesis is obvious to many.
> 
> *THESIS: All hashrates* *h' > h generate a revenue per unit of hash v' >
> v. *
> 
> Let us absurdly[1] assume that an optimal hashrate *h* exists where the
> average revenue for each hash in service is maximized. This will result
> from perpetually mining blocks of size *q,* is *v. *All larger hashrates *h'
> > h* will generate an average revenue per hash *v' < v*(effectively the
> conclusion of my paper) due to the higher orphan risk carried from having
> to mine blocks of size *q' > q*. Leading from Peter's model and my
> analysis, the origin of this balance lies in the fact that larger miners
> must somehow be forced to mine larger blocks which in turn carry a larger
> orphan risk.
> 
> What happens if a large miner *h'* chooses not to mine his optimal block
> size *q' *in favor of a seemingly "sub-optimal" block size* q*?
> Since he mines a block of identical size as the smaller miner, they will
> both carry identical orphan risks[2], and win identical
> amounts*R+M(q)* whenever
> they successfully mine a block. Since the larger miner can statistically
> expect to win *h'/h* more blocks than the smaller miner, they will each
> earn an identical revenue per unit of hash *R+M(q)/h*.
> 
> This however directly contradicts the assumption that an optimal hashrate
> exists beyond which the revenue per unit of hash *v' < v*if  *h' > h. *
> *Q.E.D *
> 
> This theorem in turn implies the following corollary:
> 
> *COROLLARY: **The marginal profit curve is a monotonically increasing of
> miner hashrate.*
> 
> This simple theorem, suggested implicitly by Gmaxwell disproves any and all
> conclusions of my work. Most importantly, centralization pressures will
> always be present.

FWIW I did a quick math proof along those lines awhile back too using
some basic first-year math, again proving that larger miners earn more
money per unit hashing power:

http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03272.html

-- 
'peter'[:-1]@petertodd.org
000000000000000010b552c5f5c18705ccb1b21c550c08872089f89076840d6d

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [bitcoin-dev] ERRATA CORRIGE + Short Theorem

[Peter R]

[-- Attachment #1.1: Type: text/plain, Size: 866 bytes --]

On 2015-09-01, at 12:56 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote
> 
> FWIW I did a quick math proof along those lines awhile back too using
> some basic first-year math, again proving that larger miners earn more
> money per unit hashing power:
> 
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03272.html

I don't believe anyone is arguing otherwise.  Miners with a larger fraction of the network hash rate, h/H, have a theoretical advantage, all other variables in the miner's profitability equation held constant.  

Dpinna originally claimed (unless I'm mistaken) that his paper showed that this advantage decreased as the block reward diminished or as the total fees increased.  This didn't seem unreasonable to me, although I never checked the math.  

Best regards,
Peter


 


[-- Attachment #1.2: Type: text/html, Size: 1438 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]

Re: [bitcoin-dev] ERRATA CORRIGE + Short Theorem

[Daniele Pinna]

[-- Attachment #1: Type: text/plain, Size: 1912 bytes --]

My paper did show that the advantage decreased with the block reward.
However, in that limit, it also seemed to imply that a network state would
appear where the revenue per unit hash decreased with increasing hashrate
which should be impossible as just discussed.

In a followup email, I showed how the origin of this effect stems from the
orphaning factor used which doesn't preserve the full network revenue per
unit block. This led me to correct my assertions by pointing out that our
miner profit equations seemed to be just lower bounds to the miner's true
expected profit. As such, just because the *lower bound* on the revenue per
unit hash advantage decreases with the block reward, this doesn't
necessarily imply that the *real* revenue per unit hash advantage does also.

I suspect that the orphaning factor used, independently of the specific
form of the block relay time, is incorrect or incomplete as stated.

Best,
Daniele

Daniele Pinna, Ph.D

On Tue, Sep 1, 2015 at 10:06 AM, Peter R <peter_r@gmx.com> wrote:

> On 2015-09-01, at 12:56 AM, Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote
>
>
> FWIW I did a quick math proof along those lines awhile back too using
> some basic first-year math, again proving that larger miners earn more
> money per unit hashing power:
>
>
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03272.html
>
>
> I don't believe anyone is arguing otherwise.  Miners with a larger
> fraction of the network hash rate, *h*/*H*, have a theoretical advantage,
> all other variables in the miner's profitability equation held constant.
>
> Dpinna originally claimed (unless I'm mistaken) that his paper showed that
> this advantage *decreased* as the block reward diminished or as the total
> fees increased.  This didn't seem unreasonable to me, although I never
> checked the math.
>
> Best regards,
> Peter
>
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2803 bytes --]