Quote from: jctech on June 07, 2014, 08:00:56 PM

Quote from: jl2012 on June 06, 2014, 10:32:02 AM

Your proposal won't work, because there is no centralized timing source.

Well, if that would be true then the difficulty adjustment would also not work. In order to be able to adjust the difficulty you need to know how long it took to generate the last 2016 blocks. So there *is* some knowledge of time. It is not exact, but it is there and it is sufficiently precise to make adjustments of difficulty that keep the block generation from getting runaway.

My idea is to use these ideas from that code that do the difficulty adjustments to implement the scenario described. Regarding the time source I was thinking about some sort of NTP-like time propagation protocol which the clients would use to track something called "current network time". A NTP service could be used by random nodes to obtain the current time but the real NTP queries should be very infrequent and made only by a few nodes, essentially the network should collectively keep track of time. The nodes shall poke throughout the network, asking random node about the time (and JUST only about the time) and then update their clock accordingly.

Difficulty adjustment works because it happens only once in 2016 blocks. An attacker trying to manipulate timestamp will only produce a very small effect on the difficulty. There are already many discussion saying why it is a bad idea to adjust difficulty for each single block

As mentioned earlier, if we had a reliable decentralised NTP service, we don't even need a blockchain in the first place. Your proposal is like trying to lifting yourself off from the ground with your own hands.

And finally, if someone owning 99% of hashing power decides to attack the network, there are many many ways to do so. Even if you system could be successfully implemented, the attacker could keeping mining empty blocks so no transactions may go through.