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 AC79DF43 for ; Sat, 26 Dec 2015 18:02:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com [209.85.213.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BC010EC for ; Sat, 26 Dec 2015 18:02:00 +0000 (UTC) Received: by mail-vk0-f49.google.com with SMTP id k1so38218111vkb.2 for ; Sat, 26 Dec 2015 10:02:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rt0RhQc+ILv4m2RAWdilNLGvTlk578nNRSSdAabVnFQ=; b=ifdeN5Heq2OMk3+BZiMd83UCZXD+lC/44O3IjFCVDJ+1Oxmeho5c4zEeSfjNv1iAlv KDLTPmhP3wEKs4ZuBRLLo1QCNV9l2vFbx+pEaFx+bsUbLIPdDnJzpLrDPzX15R3XRchz HeWugBlfIt+japWlpuBwvitJvKBbWN85m/woMSEBHcydoecRJ1Q7lzVDOiXSmIRalxCq qWJxculvHuU+bW68aEVOKV/jIarva1wvFIeKEaBZLJLtBPMjGiSRHfjBLQSIRjh/zdxi spggRCN9Lwx4oydjkMznRxlKpsZIzXKZRPTGb2aoaU8v9hS50rTeyneWGRO/DwJS/q2k wwNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rt0RhQc+ILv4m2RAWdilNLGvTlk578nNRSSdAabVnFQ=; b=Hua2D+NIZtfuXXyXD8yz7FwC2FCZkkeyqNtaem+bH6Y+FvtPFFcEnNbH0w7iYpKZA5 GXF3KMSd7tX95pPVNryX0MqUpFwGPQhNGn61Ip9xO//HMjOAzdtvbe2judE605W1zyHM 8z4eVuDDnK/cSGG5TAFNCX2Wskg9pVxp9EoDUc2+NgvBIeS7UhjcDodEHWHQEDm1mDN8 wG72wHQTklO+qWznXCor3VsHkSfW03x79ojNPAQFi4fxq3/3mbod+MCoCmUyY7cpY82b sqFXBM03E5qKNRkDphTlbaLuz3vvEFIhkgKf9pP4i4oFUzms/ci3+Zno4JIubMueH9pM VJEA== X-Gm-Message-State: ALoCoQkx9e6ku7+XmQ4sDNI/IG8SPzP3do9dMhGXGoI8V/Vu+/iTHIW50qAycP3r3r8ADNe6rLijYM6jvMPhakVGgreZ369TTQ== MIME-Version: 1.0 X-Received: by 10.31.6.131 with SMTP id 125mr29482665vkg.140.1451152919896; Sat, 26 Dec 2015 10:01:59 -0800 (PST) Received: by 10.31.141.73 with HTTP; Sat, 26 Dec 2015 10:01:59 -0800 (PST) Received: by 10.31.141.73 with HTTP; Sat, 26 Dec 2015 10:01:59 -0800 (PST) In-Reply-To: References: <20151220132842.GA25481@muck> Date: Sat, 26 Dec 2015 19:01:59 +0100 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Eric Lombrozo Content-Type: multipart/alternative; boundary=001a1143da624e396d0527d0de34 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 , nbvfour@gmail.com Subject: Re: [bitcoin-dev] We need to fix the block withholding attack 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: Sat, 26 Dec 2015 18:02:02 -0000 --001a1143da624e396d0527d0de34 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The hashpower is a function of the block reward (subsidy + fees): it's economically irrational to have costs greater than the reward (better just turn off your miners) and in a perfect competition (a theoretical model) profits tend to zero. That is, the costs tend to equal revenue (block reward). On Dec 26, 2015 6:38 PM, "Eric Lombrozo" wrote: > For simplicity, assume total network hashpower is constant. Also, assume > the soft fork activates at the beginning of a retarget period. > > At the moment the soft fork activates, the effective difficulty is > increased (by adding a second independent PoW check that must also be > satisfied) which means more hashes on average (and proportionally more > time) are required to find a block. At the end of the retarget period, th= e > difficulty is lowered so that if the second PoW difficulty were to be kep= t > constant the block interval would again average 10 mins. > > If we were to keep the second PoW difficulty constant, we would restore > the same total PoW-to-time-unit ratio and the retarget difficulty would > stabilize again so each block would once more require the same number of > hashes (and same amount of time) on average as before. > > But we don't keep the second PoW difficulty constant - we increase it so > once again more hashes on average are required to find a block by the sam= e > proportion as before. And we keep doing this. > > Now, the assumption that hashpower is constant is obviously unrealistic. > If this is your bone of contention, then yes, I agree my model is overly > simplistic. > > My larger point was to explore the extent of what's possible with only a > soft fork - and we can actually go pretty far and even compensate for the= se > economic shifts by increasing block size and rewards. The whole thing is > clearly a huge mess - and I wouldn't recommend actually doing it. > > > > On December 26, 2015 7:33:53 AM PST, "Jorge Tim=C3=B3n" > wrote: >> >> >> On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> > Unfortunately, this also means longer confirmation times, lower >> throughput, and lower miner revenue. Note, however, that confirmations >> would (on average) represent more PoW, so fewer confirmations would be >> required to achieve the same level of security. >> > >> >> I'm not sure I understand this. If mining revenue per unit of time drops= , >> total pow per unit of time should also drop. Even if the inter-block tim= e >> is increased, it's not clear to me that the pow per block would necessar= ily >> be higher. >> What am I missing? >> > --001a1143da624e396d0527d0de34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The hashpower is a function of the block reward (subsidy + f= ees): it's economically irrational to have costs greater than the rewar= d (better just turn off your miners) and in a perfect competition (a theore= tical model) profits tend to zero. That is, the costs tend to equal revenue= (block reward).

On Dec 26, 2015 6:38 PM, "Eric Lombrozo&quo= t; <elombrozo@gmail.com> w= rote:
For simpl= icity, assume total network hashpower is constant. Also, assume the soft fo= rk activates at the beginning of a retarget period.

At the moment the soft fork activates, the effective difficulty is increase= d (by adding a second independent PoW check that must also be satisfied) wh= ich means more hashes on average (and proportionally more time) are require= d to find a block. At the end of the retarget period, the difficulty is lo= wered so that if the second PoW difficulty were to be kept constant the blo= ck interval would again average 10 mins.

If we were to keep the second PoW difficulty constant, we would restore the= same total PoW-to-time-unit ratio and the retarget difficulty would stabil= ize again so each block would once more require the same number of hashes (= and same amount of time) on average as before.

But we don't keep the second PoW difficulty constant - we increase it s= o once again more hashes on average are required to find a block by the sam= e proportion as before. And we keep doing this.

Now, the assumption that hashpower is constant is obviously unrealistic. If= this is your bone of contention, then yes, I agree my model is overly simp= listic.

My larger point was to explore the extent of what's possible with only = a soft fork - and we can actually go pretty far and even compensate for the= se economic shifts by increasing block size and rewards. The whole thing is= clearly a huge mess - and I wouldn't recommend actually doing it.



On December 26, 2015 7:33:53 AM PST, &qu= ot;Jorge Tim=C3=B3n" <jtimon@jtimon.cc> wrote:


On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" <bitc= oin-dev@lists.linuxfoundation.org> wrote:
=C2=A0
> Unfortunately, this also means longer confirmation times, lower throug= hput, and lower miner revenue. Note, however, that confirmations would (on = average) represent more PoW, so fewer confirmations would be required to ac= hieve the same level of security.
> =C2=A0

I'm not sure I understand this. If mining revenue per un= it of time drops, total pow per unit of time should also drop. Even if the = inter-block time is increased, it's not clear to me that the pow per bl= ock would necessarily be higher.
What am I missing?

--001a1143da624e396d0527d0de34--