From: Tom Harding <tomh@thinlink•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize
Date: Wed, 9 Sep 2015 12:53:10 -0700 [thread overview]
Message-ID: <55F08E26.9000200@thinlink.com> (raw)
In-Reply-To: <CAEz79PrV0OOZ+V-YLP4bTyfaHhbMqrP6TAyu-Lt27_guA+wMzg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]
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
> <mailto: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
[-- Attachment #2: Type: text/html, Size: 3204 bytes --]
next prev parent reply other threads:[~2015-09-09 19:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-14 9:59 Jakob Rönnbäck
2015-08-14 13:32 ` Angel Leon
2015-08-14 14:19 ` Jakob Rönnbäck
2015-08-14 16:37 ` [bitcoin-dev] libconsensus assertion fails if used in multiple threads Tamas Blummer
2015-08-14 21:10 ` Cory Fields
2015-08-18 5:03 ` Cory Fields
2015-08-18 10:31 ` Tamas Blummer
2015-08-18 17:25 ` Cory Fields
2015-08-18 17:50 ` Cory Fields
2015-08-18 21:40 ` Eric Voskuil
2015-08-14 14:20 ` [bitcoin-dev] Adjusted difficulty depending on relative blocksize Anthony Towns
[not found] ` <A6B32C22-4006-434E-9B89-D7C99B5743A8@me.com>
2015-08-14 14:48 ` Jakob Rönnbäck
2015-08-14 15:00 ` Anthony Towns
2015-08-14 15:03 ` Adam Back
2015-08-14 15:14 ` Jakob Rönnbäck
2015-09-09 3:27 ` Tom Harding
2015-09-09 18:59 ` Warren Togami Jr.
2015-09-09 19:53 ` Tom Harding [this message]
2015-08-14 22:12 ` Tom Harding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55F08E26.9000200@thinlink.com \
--to=tomh@thinlink$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox