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