Re: [Bitcoin-development] Addressing rapid changes in mining power

[Christian Decker <decker.christian@gmail.com>]

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

First of all I do agree that a method for adjusting the difficulty in a
huge power drop is needed (I don't see it so much in power rises).

The current block generation with a fixed difficulty was chosen because it
it clear when to adjust and to what target difficulty it has to be
adjusted. If we were to use synchronized time windows and select the
hardest block it gets incredibly complicated as synchronization is not
possible in distributed systems. Even the smallest drift would allow for
forks in the chain all over the place. Furthermore the delay in propagation
will also cause forks.

If 1/2 of the network see one block as the hardest, and for the rest of the
network it came too late then we'll have a fork that stays with us quite a
while.

The block chain is described as a timestamp server in the paper, but it is
more of a proof-of-existence before, as the contained timestamp cannot be
trusted anyway.

Regards,
Chris

2011/11/23 Jorge Timón <timon.elviejo@gmail.com>

> With the current system, the timestamp can also be cheated, but miners
> have no direct incentive to do it. With your system, they increase
> their probability of mining a block by putting a false timestamp.
> Also, where's the network clock you're talking about? Isn't it the
> timestamps in the blockchain?
>
>
>
> 2011/11/23, Andy Parkins <andyparkins@gmail.com>:
> > On 2011 November 23 Wednesday, Jorge Timón wrote:
> >> 2011/11/23, Andy Parkins <andyparkins@gmail.com>:
> >> > Let's abandon the idea of a target difficulty.  Instead, every node
> just
> >> >
> >>  > generates the most difficulty block it can.  Simultaneously, every
> node
> >>  > is listening for "the most difficult block generated before time T";
> >>  > with T being
> >>  > picked to be the block generation rate (10 minutes).
> >>
> >> A miner could try to obtain more difficulty out of time and cheat its
> >> reported datetime (T).
> >
> > Just as with the current system.
> >
> > The defence is that on receipt of a block, its timestamp is checked
> against
> > the node's own clock and averaged network clock.  Blocks out of that band
> > are
> > rejected.
> >
> >
> > Andy
> > --
> > Dr Andy Parkins
> > andyparkins@gmail.com
> >
>
>
> --
> Jorge Timón
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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