The biggest problem with a time based rule is that there is no central time to provide a measure of how much time has actually passed. You can see this issue on testnet already because block timestamps are modified. For example, the current time is (according to my server) 1410626564 and the best block on testnet shows a timestamp of 1410628433 (30 minutes in the future).
On Sep 13, 2014, at 12:34 PM, Jeff Garzik <jgar...@bitpay.com> wrote: > Why not on mainnet? It is simply much lower priority for bitcoin > today than other problems. It tends not to happen at higher > difficulties for a variety of reasons. > > The difficulty adjustment is capped at a factor of 4, up or down, to > address some other attacks that can happen in mining. > > Personally, I think there needs to be a mainnet safety rule such as > "if 24 hours goes by without a block, you may mine a block" etc. But > I readily admit I've not thought through all the ramifications of such > a policy. > > > > On Sat, Sep 13, 2014 at 12:00 PM, s7r <s...@sky-ip.org> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >> On 9/13/2014 5:04 PM, Jeff Garzik wrote: >>> This is why testnet has a special rule: If 20 minutes passes >>> without a block, you may mine a diff-1 block. >>> >> >> Thanks for your point of view Mr. Garzik. >> Why aren't we using this in the real bitcoin network too? If it's good >> for balancing the functionality of the network in the context of >> sudden hashrate moves? Specially down moves, since if the hash power >> goes UP, the network will see blocks are created more often than at >> every 10 minutes and adjust the difficulty directly proportional, correct? >> >>> >>> On Sat, Sep 13, 2014 at 9:15 AM, s7r <s...@sky-ip.org> wrote: Hi >>> there, >>> >>> I have an contradictory discussion with an altcoin supporter and >>> want to bring some solid arguments in a public talk, so require >>> little help to respond to a question with simplest answer. >>> >>> The problem is within the difficulty adjustment mechanism, that it >>> happens at every 2016 blocks. In case the hash power will suddenly >>> decrease, the 2016 blocks will take a lot of time to solve, >>> therefor freeze the network in a non-operational way. I know by far >>> this is just a joke, because this is very unlikely to happen >>> anytime (people paid for mining equipment and make money) but for >>> the sake of discussion, let's just assume it 'could' happen. >>> >>> Can this really freeze the network for unlimited time and bitcoin >>> has no mechanism to balance it back? A resourceful party with the >>> intent to attack the network in an irrational way, brings lot of >>> hashing power and keeps it for 2016 blocks, then removes it leaving >>> the other 2016 blocks to solve at very high difficulty but with low >>> hash power in the network causing a 'blackout'? Thank you in >>> advance for your answers. >>> >>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> >> Want excitement? >>>> Manually upgrade your production database. When you want >>>> reliability, choose Perforce Perforce version control. >>>> Predictably reliable. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk >>>> >>>> >> _______________________________________________ >>>> bitcoin-list mailing list bitcoin-list@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-list >>> >>> >>> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.22 (MingW32) >> >> iQEcBAEBAgAGBQJUFGo4AAoJEIN/pSyBJlsR3d0IAISkymj6mxOkifdmp6ujUL4y >> 7lVoROugxAKTen9Fhg4rtWC10HQkTClJVfmaUYb+3D+oJ6YFjvZeyYT9TxFBrnvC >> JfKG6m/yc9yp/R1MwSL81ez8TQvBt1UUVZcxApYW1TWXJDH95ua5IakQDkag/dET >> HUtCAabPTDtQf0UaFqcycVXcXRYjvH73pOOD5j4WBeW1M2kd7pLm9Zdh1Up7nWVK >> hfISwfq2S39vMBb5474/WP38YymW0izjh9yrxMaNT3MeuxR3PUo5ue9O470+YP5Y >> 5k03vs+qF3GWYRIy+13x//WeiYPQQxONjxb4+mgcfoYpXjx611VKPpYjZGarTNU= >> =JCev >> -----END PGP SIGNATURE----- > > > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > ------------------------------------------------------------------------------ > Want excitement? > Manually upgrade your production database. > When you want reliability, choose Perforce > Perforce version control. Predictably reliable. > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk > _______________________________________________ > bitcoin-list mailing list > bitcoin-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-list ------------------------------------------------------------------------------ Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk _______________________________________________ bitcoin-list mailing list bitcoin-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-list
