Re: [Bitcoin-development] Difficulty adjustment / time issues

[Gavin Andresen <gavinandresen@gmail.com>]

> 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 bitcoin
> clock rather than the, ahem, real clock.  If we change the idea of network
> 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.

-- 
--
Gavin Andresen