From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A92F3146D for ; Tue, 1 Sep 2015 08:53:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E489F12D for ; Tue, 1 Sep 2015 08:53:07 +0000 (UTC) Received: by lbvd4 with SMTP id d4so38544236lbv.3 for ; Tue, 01 Sep 2015 01:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2apURqucK9M63DGypn2oNQxhYzG+cPSFA98vWQIgplE=; b=aqvuRVkta9VWoTI33l/cEdh8GyA/YFK/hDRB/iwjCI4LvKrujeB/MDz5I7fOLTn15a QH6ecLRhDN5GqlzilxUCkbZG0VLerG7M+aYWIsRFhAh2Rx9AwDykU34AuGojaEGUxfuD s8Nsywyu2fwLAk1e2ORyfFyBD99ScqE6UmF0hb+877Q7etPW3LGLAZerboC5bQv2bckv CSOKNhaEEKvQVezaXNpi5yhXAGmRgTNBtqjMToFYfox9Qcrnxb3SKSUzkfdTUaeShtQx 5+b4Vn5iSrGFQnmHxGK/iFRZlu7+uxvvbkjpPinOqJ6LqUmO0tZ+CVJ1N4iZs33iDixy 9xbQ== X-Received: by 10.152.23.167 with SMTP id n7mr12586458laf.108.1441097586011; Tue, 01 Sep 2015 01:53:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.143.229 with HTTP; Tue, 1 Sep 2015 01:52:46 -0700 (PDT) In-Reply-To: <7E54183F-DDBD-4EFB-828B-841350A80E33@gmx.com> References: <20150901075613.GD17380@muck> <7E54183F-DDBD-4EFB-828B-841350A80E33@gmx.com> From: Daniele Pinna Date: Tue, 1 Sep 2015 10:52:46 +0200 Message-ID: To: Peter R Content-Type: multipart/alternative; boundary=089e0160a5e6b3737c051eabad44 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 Subject: Re: [bitcoin-dev] ERRATA CORRIGE + Short Theorem 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: Tue, 01 Sep 2015 08:53:08 -0000 --089e0160a5e6b3737c051eabad44 Content-Type: text/plain; charset=UTF-8 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 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 > > > > > --089e0160a5e6b3737c051eabad44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My paper did show that the advantage decreased with the bl= ock reward. However, in that limit, it also seemed to imply that a network = state would appear where the revenue per unit hash decreased with increasin= g hashrate which should be impossible as just discussed.

In a follow= up email, I showed how the origin of this effect stems from the orphaning f= actor used which doesn't preserve the full network revenue per unit blo= ck. This led me to correct my assertions by pointing out that our miner pro= fit equations seemed to be just lower bounds to the miner's true expect= ed profit. As such, just because the lower bound on the revenue per = unit hash advantage decreases with the block reward, this doesn't neces= sarily imply that the real=C2=A0revenue per unit hash advantage does= also.

I suspect that the orphaning factor used, independently of th= e specific form of the block relay time, is incorrect or incomplete as stat= ed.

Best,
Daniele

Daniele Pinna, Ph.D

On Tue, Sep 1, 2015 at 10:06 AM, Peter R <pet= er_r@gmx.com> wrote:
On 2015-09-01, at 12:56 AM, Peter T= odd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote=

FWIW I did a quick mat= h proof along those lines awhile back too using
some basic first-year ma= th, again proving that larger miners earn more
money per unit hashing po= wer:

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

I don't believe anyone is arguing otherwise.= =C2=A0 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. =C2=A0

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

Best regards,
Peter


=C2=A0


--089e0160a5e6b3737c051eabad44--