Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.161.47 as permitted sender)
	client-ip=209.85.161.47; envelope-from=gavinandresen@gmail.com;
	helo=mail-fx0-f47.google.com; 
MIME-Version: 1.0
In-Reply-To: <4E6F83C3.9020108@jerviss.org>
References: <CABsx9T2XLj4gZVPYodteaVCm0chR1n4WLUoSqB6+NnmWCDqHKQ@mail.gmail.com>
	<4E6F83C3.9020108@jerviss.org>
Date: Wed, 14 Sep 2011 10:45:36 -0400
Message-ID: <CABsx9T0JvnOaBy+irHtnN1zMWP8FiDTn=kn-01ky+V2MW1suTg@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: kjj <kjj@jerviss.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Difficulty adjustment / time issues
Precedence: list

> But that doesn't solve the whole problem, because the block timestamp
> checking is based on the assumption that the node is looking at the bitco=
in
> clock rather than the, ahem, real clock. =A0If we change the idea of netw=
ork
> time to NTP, we will then need to write (and test!) new block timestamp
> rules to account for the new assumptions.

Why?

The block timestamp rules currently give HOURS of wiggle-room for
timestamps. We can't change those rules without risking a chain split.

Here's a thumbnail sketch of what I'm thinking:

When new tip-of-chain blocks are received, IF their timestamp is
unreasonable with respect to system time and the previous block's
timestamp, then add them to a 'discouraged' list.  (but follow the
current rules for outright rejecting blocks based on timestamps too
far in the future or past)

Modify the getwork code to build on the second-from-tip block if the
first-on-tip block is on the discouraged list.

Assuming a majority of pools/miners adopt the "discourage blocks with
stale timestamps" rule, that should squash any incentive for cartels
to try to start playing with difficulty-- you would have to have 50+%
power to start, or you risk producing mostly orphan blocks.

> Also, this is going to cause problems for at least one pool operator.

I'll trade more security for "make at least one pool operator have to
do some work" any day.

--=20
--
Gavin Andresen