That is conflating two different things. Block timestamps are never "modified." Miners are permitted to mine timestamps within a certain time range (e.g. no more than 2 hours into the future). That is normal for testnet or mainnet.
On Sat, Sep 13, 2014 at 12:45 PM, Michael Wozniak <m...@osfda.org> wrote: > 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 ------------------------------------------------------------------------------ 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
