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 675A0ECF for ; Wed, 9 Sep 2015 19:53:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EDC3D30C for ; Wed, 9 Sep 2015 19:53:33 +0000 (UTC) Received: by padhk3 with SMTP id hk3so19138413pad.3 for ; Wed, 09 Sep 2015 12:53:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=fvC1MjlxUg1/tmvLyU+mrgcBXKNDnQ5+LcLYrnvCjPE=; b=TqM2jMSeUntUMcDtuGh3cph5nBkyawGVayRLokql9BaUUsZaOmlFP+8BM7h6kzBCwW 0dXtsipjB+XiYgTlMcEwvLTxxC1hbxHEEgXshSxap9FF2DeE0Dp6sE/yWwzQBnoVj1vE YqaroWCWs+CzhWKai8Occ0x4CH7YWuYIDd+kiJRcNyiAWPqmvtNsHlce4VHfL61XBeNi gFvA75w7YlM/yna6c7oXlMMqdyTZAdO0gpyh05cHfaUaZM7e01pSZ3nT90PbOkLnTz76 KcW3BxOZ1dJhai5TTfIoj3x/754UoPT98v2d8YI8Ly8EwnBBrOnr5j83L2I6ddJ24h2e CKCA== X-Gm-Message-State: ALoCoQlCuWFgD6TBIAmtHRf36vHU/CSvZTY/xpJp/ZgeeoZgHEm9YcpjlugejxBLmckJDQC57GU7 X-Received: by 10.68.69.40 with SMTP id b8mr61707051pbu.84.1441828413693; Wed, 09 Sep 2015 12:53:33 -0700 (PDT) Received: from [10.100.1.239] ([204.58.254.99]) by smtp.googlemail.com with ESMTPSA id k2sm1228465pdc.45.2015.09.09.12.53.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Sep 2015 12:53:32 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: <09C8843E-8379-404D-8357-05BDB1F749C1@me.com> <116B26BD-D8E8-4AFD-A619-2EAC348DA5E6@me.com> <55EFA71A.1080102@thinlink.com> From: Tom Harding Message-ID: <55F08E26.9000200@thinlink.com> Date: Wed, 9 Sep 2015 12:53:10 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080301060606050802020205" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_WEB autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize 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: Wed, 09 Sep 2015 19:53:35 -0000 This is a multi-part message in MIME format. --------------080301060606050802020205 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Well let's see. All else being equal, if everybody uses difficulty to buy big blocks during retarget interval 0, blocks and therefore money issuance is slower during that interval. Then, the retargeting causes it to be faster during interval 1. Subsidy got shifted from the calendar period corresponding to interval 0, to interval 1. If you change the reward, you can lower the time-frame of the effect to the order of a single block interval, but there is still an effect. These schemes do not avoid the need for a hard cap, and there are new rules for the size of the allowed adjustment, in addition to the main rule relating difficulty to block size. So it seems they generally have more complexity than the other blocksize schemes being considered. On 9/9/2015 11:59 AM, Warren Togami Jr. via bitcoin-dev wrote: > Does it really change the schedule when the next difficulty retarget > readjusts to an average of 10 minutes again? > > On Tue, Sep 8, 2015 at 8:27 PM, Tom Harding via bitcoin-dev > > wrote: > > > There is another concern regarding "flexcap" that was not discussed. > > A change to difficulty in response to anything BUT observed block > production rate unavoidably changes the money supply schedule, unless > you also change the reward, and in that case you've still changed the > timing even if not the average rate. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --------------080301060606050802020205 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Well let's see.  All else being equal, if everybody uses difficulty to buy big blocks during retarget interval 0, blocks and therefore money issuance is slower during that interval.  Then, the retargeting causes it to be faster during interval 1.  Subsidy got shifted from the calendar period corresponding to interval 0, to interval 1.

If you change the reward, you can lower the time-frame of the effect to the order of a single block interval, but there is still an effect.

These schemes do not avoid the need for a hard cap, and there are new rules for the size of the allowed adjustment, in addition to the main rule relating difficulty to block size.  So it seems they generally have more complexity than the other blocksize schemes being considered.


On 9/9/2015 11:59 AM, Warren Togami Jr. via bitcoin-dev wrote:
Does it really change the schedule when the next difficulty retarget readjusts to an average of 10 minutes again? 

On Tue, Sep 8, 2015 at 8:27 PM, Tom Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

There is another concern regarding "flexcap" that was not discussed.

A change to difficulty in response to anything BUT observed block
production rate unavoidably changes the money supply schedule, unless
you also change the reward, and in that case you've still changed the
timing even if not the average rate.



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--------------080301060606050802020205--