Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of mm.st
	designates 66.111.4.27 as permitted sender)
	client-ip=66.111.4.27; envelope-from=theymos@mm.st;
	helo=out3.smtp.messagingengine.com; 
Message-Id: <1316036733.29037.140258141218893@webmail.messagingengine.com>
From: "theymos" <theymos@mm.st>
To: bitcoin-development@lists.sourceforge.net
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
In-Reply-To: <CABsx9T2XLj4gZVPYodteaVCm0chR1n4WLUoSqB6+NnmWCDqHKQ@mail.gmail.com>
References: <CABsx9T2XLj4gZVPYodteaVCm0chR1n4WLUoSqB6+NnmWCDqHKQ@mail.gmail.com>
Date: Wed, 14 Sep 2011 16:45:33 -0500
Subject: Re: [Bitcoin-development] Difficulty adjustment / time issues
Precedence: list

A better retarget strategy might be to use the real average time
between all of the blocks in the interval so that no blocks are
treated specially in the calculation. I agree that this is not
important enough to fork the chain over, though. An attacker would
have to maintain control for a *very* long time because of Bitcoin's
long retarget interval. (Maybe this kind of thing is why the retarget
interval is so long?)

I don't like requiring block times to be within minutes of reality. It
would be fine if only miners had to keep accurate time, but clients will
also need to have good time in order to see if a block will be
discouraged. A discouraged block should not count toward confirmations.
If relays will also discourage blocks, then they'll need accurate
time as well.

The network should not be allowed to adjust your time by more than 40
minutes to prevent the timejacking attack, but I don't see a problem
with the other time rules. Time is only used for retargets and LockTime,
so it only needs to be generally accurate.