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
