Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

From: Dave Scotese <dscotese@litmocracy•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm
Date: Wed, 2 Mar 2016 21:11:16 -0800	[thread overview]
Message-ID: <CAGLBAhcL+Z7uPVG6U5cEShc52KmkYFb6USF_gk6bZaj2SFv37A@mail.gmail.com> (raw)
In-Reply-To: <20160302230213.GA888@muck>

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

It makes sense to me that there might be objective conditions under which
we would want to use a number smaller than 2016.  A good example would be a
mean time between blocks of more than 20 minutes over the last 144 blocks
(one  - two days).  If such an occurrence ever happened, and the software
then cut the retarget interval to 1008 (triggering an immediate retarget if
the counter is over 1008), the only problem I see is how to measure the
mean time between blocks.

In fact, has anyone examined the potential problems of reducing the
retarget period, even to one?  Not Really.
<http://bitcoin.stackexchange.com/questions/9305/why-not-retarget-on-every-block>
That question includes a suggestion of retargeting on every block, but
using the same 2016 block window for the calculation, so difficulty changes
would be very smooth, and still as unpredictable and how long till we find
the next block.

On Wed, Mar 2, 2016 at 3:02 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> On Wed, Mar 02, 2016 at 11:01:36AM -0800, Eric Voskuil via bitcoin-dev
> wrote:
> > > A 6 month investment with 3 months on the high subsidy and 3 months on
> low subsidy would not be made…
> >
> >
> >
> > Yes, this is the essential point. All capital investments are made based
> on expectations of future returns. To the extent that futures are perfectly
> knowable, they can be perfectly factored in. This is why inflation in
> Bitcoin is not a tax, it’s a cost. These step functions are made continuous
> by their predictability, removing that predictability will make them --
> unpredictable.
>
> You know, I do agree with you.
>
> But see, this is one of the reasons why we keep reminding people that
> strictly speaking a hardfork *is* an altcoin, and the altcoin can change
> any rule currently in Bitcoin.
>
> It'd be perfectly reasonable to create an altcoin with a 22-million-coin
> limit and an inflation schedule that had smooth, rather than abrupt,
> drops. It'd also be reasonable to make that altcoin start with the same
> UTXO set as Bitcoin as a means of initial coin distribution.
>
> If miners choose to start mining that altcoin en-mass on the halving,
> all the more power to them. It's our choice whether or not we buy those
> coins. We may choose not to, but if 95% of the hashing power decides to
> go mine something different we have to accept that under our current
> chosen rules confirmations might take a long time.
>
>
> Of course, personally I agree with Gregory Maxwell: this is all fairly
> unlikely to happen, so the discussion is academic. But we'll see.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> 000000000000000004d430e1daab776bc1c194589b0326924220faa00efc50cf
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

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