From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Date: Wed, 14 Sep 2011 19:01:54 -0400
User-Agent: KMail/1.13.7 (Linux/2.6.39-gentoo; KDE/4.6.5; x86_64; ; )
References: <CABsx9T2XLj4gZVPYodteaVCm0chR1n4WLUoSqB6+NnmWCDqHKQ@mail.gmail.com>
	<CAB=c7TpFE_28BNpkW27kKK41w8QdaMKJ96=6H=xqonVDdTWUkA@mail.gmail.com>
	<CAAS2fgQOuNKWD09arSzqKxYFRv95q4xyq0Wz4ZkeKdKSWJ-=kA@mail.gmail.com>
In-Reply-To: <CAAS2fgQOuNKWD09arSzqKxYFRv95q4xyq0Wz4ZkeKdKSWJ-=kA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201109141901.57286.luke@dashjr.org>
Cc: kjj <kjj@jerviss.org>
Subject: Re: [Bitcoin-development] Difficulty adjustment / time issues
Precedence: list

On Wednesday, September 14, 2011 4:09:00 PM Gregory Maxwell wrote:
> Though I generally agree with Luke that we should just fix the root
> cause even though it forks the chain.

I don't support this, unless all other chain-forking-needed changes are mad=
e=20
at the same time. I do point out that changing the time rules *does not hel=
p*.

> Not for his reasons (I don't give a crap about the burden on _one_ pool
> operator=E2=80=94 the rest cope with bitcoind scaling fine without excess=
ive
> dependance on ntime rolling),

The rest don't generate rewards immediately as the same block being mined.=
=20
They either eat the loss of invalid blocks, or wait for 100+ confirmations=
=20
before paying. Also, restricting the time rules basically breaks miners=20
without rollntime support (such as Phoenix).