Time for another testnet reset?

[BTCurious]

The widespread adoption or merged mining for bitcoin/testnet would solve the problem of volatile difficulty.

But not for people wanting to test mining. Or including weird scripts. Or excluding weird scripts. Or maybe the people sending weird scripts will hardly ever get them accepted.

[Disposition]

Three proposed changes to simulate testnet to what the Future for Bitcoin will look like.

• Fixed Difficulty/Fast Adjusted Difficulty as in the future I do not suspect difficulty to change too much. e.g. controlled environment.
  
• No BTC generated per block like in the future, block are mined purely for quickly confirming/verifying transactions.
• 21 Million testnet BTC generated in Genesis Block, emulating the future of circulation, transfer to faucet.

This will make testing much faster,
one can fire up miner, point to testnet,
request coins from faucet, proceed to test,
send coins back, shut off miner.

[Gavin Andresen]

In the spirit of "do the simplest possible thing that works..."  I think I see a very simple thing that will work.

The simple additional rule for the testnet:

If current_block_timestamp - previous_block_timestamp > 20 minutes:
  block difficulty = minimum difficulty

And that's it.

If mining is proceeding normally and most blocks are produced in less than 20 minutes, then the rules are exactly the same as the main network.

But if somebody has driven difficulty way up, then the new rule acts as a safety valve, ensuring that new blocks are created at least once every 20-something minutes or so.  After a month of "safety valve blocks" the difficulty would be calculated as normal, and would get cut in (approximately) half.

This does make the testnet block chain more susceptible to forks -- somebody with a bunch of hashing power can pretty easily invalidate a long chain of 20-minute, min-difficulty blocks if they want to. And there is likely to be a flurry min-difficulty blocks produced/announced every 20 minutes. But that could be considered a feature (test your block-chain-reorganization code!).

[SomeoneWeird]

In the spirit of "do the simplest possible thing that works..."  I think I see a very simple thing that will work.

The simple additional rule for the testnet:

If current_block_timestamp - previous_block_timestamp > 20 minutes:
  block difficulty = minimum difficulty

And that's it.

If mining is proceeding normally and most blocks are produced in less than 20 minutes, then the rules are exactly the same as the main network.

But if somebody has driven difficulty way up, then the new rule acts as a safety valve, ensuring that new blocks are created at least once every 20-something minutes or so.  After a month of "safety valve blocks" the difficulty would be calculated as normal, and would get cut in (approximately) half.

This does make the testnet block chain more susceptible to forks -- somebody with a bunch of hashing power can pretty easily invalidate a long chain of 20-minute, min-difficulty blocks if they want to. And there is likely to be a flurry min-difficulty blocks produced/announced every 20 minutes. But that could be considered a feature (test your block-chain-reorganization code!).

+1

[jojkaart]

In the spirit of "do the simplest possible thing that works..."  I think I see a very simple thing that will work.

The simple additional rule for the testnet:

If current_block_timestamp - previous_block_timestamp > 20 minutes:
  block difficulty = minimum difficulty

And that's it.

If mining is proceeding normally and most blocks are produced in less than 20 minutes, then the rules are exactly the same as the main network.

But if somebody has driven difficulty way up, then the new rule acts as a safety valve, ensuring that new blocks are created at least once every 20-something minutes or so.  After a month of "safety valve blocks" the difficulty would be calculated as normal, and would get cut in (approximately) half.

This does make the testnet block chain more susceptible to forks -- somebody with a bunch of hashing power can pretty easily invalidate a long chain of 20-minute, min-difficulty blocks if they want to. And there is likely to be a flurry min-difficulty blocks produced/announced every 20 minutes. But that could be considered a feature (test your block-chain-reorganization code!).

How about, instead of sharp min difficulty, start scaling the difficulty down smoothly from, maybe 15 minutes and have it reach min difficulty at 20 minutes from last block. This would also mean that miners should remember the best block they've made so far. It might end up being the one that gets accepted.

However, this sounds like it would be exploitable since the timestamp for a block can be quite a bit in the past.

[Gavin Andresen]

How about, instead of sharp min difficulty, start scaling the difficulty down smoothly from, maybe 15 minutes and have it reach min difficulty at 20 minutes from last block.

Why?  What problem would that solve?

[jojkaart]

How about, instead of sharp min difficulty, start scaling the difficulty down smoothly from, maybe 15 minutes and have it reach min difficulty at 20 minutes from last block.

Why?  What problem would that solve?

If you intend this feature to stay with testnet, what you suggested is probably fine. However, dropping difficulty sharply to the minimum would result in quite a flood of blocks competing with each other. Scaling the difficulty down slowly would reduce that a lot.

[pc]

And just to be clear, this rule will fork the test blockchain between those running on the current or prior versions of the client, and those running on whatever version this change comes out in, right?

[Gavin Andresen]

And just to be clear, this rule will fork the test blockchain between those running on the current or prior versions of the client, and those running on whatever version this change comes out in, right?

Yes.

Any opinions on whether to do a hard reset (new genesis block with the new rules) or a split ("new rules apply to blocks with timestamps after XYZ") ?


RE: scaling down difficulty:  good idea if we were thinking of implementing something like this for the main network.  But I'd want to give everybody lots of time to think long and hard about potential hacks/exploits/unintended consequences if this was being considered for the main network-- sudden drops in hashing power is NOT a problem for the main network, so I don't think it is worth considering now.

[dree12]

Is there a way to make sure people don't just modify timestamps to get extra coins? I'm sure I'm missing something, but I can't quite see what it is.

[BTCurious]

to get extra coins?

This is the testnet we're talking about… coins on the testnet have no value…

[Gavin Andresen]

Yes, who cares if you get extra testnet coins?

But... if somebody wanted to be annoying, they'd pre-generate as long a min-difficulty coinbase-only-transaction chain as the block timestamp rules allowed, and constantly broadcast those blocks.  Just to prevent transactions from getting confirmed.

To prevent that...

Testnet could prefer to build on blocks with more transactions from the memory pool over blocks with fewer transactions from the memory pool (that's not a bad rule for main net, either; might be worth considering if it works well for testnet). The rule now is "build on first valid block seen".

And "discourage" (refuse to directly build on or relay) blocks with timestamps in the future.

[BTCurious]

Is testnet trolling really an issue at the moment? I could imagine no one will really bother, since the worst thing you'll cause us mild  annoyance. Testing a feature for mainnet may be a worthy goal though.

About the suggestion itself: I believe it would open the doors for a new kind of attack. If you have ten prevent of the hashing power, but include loads of phoney transactions in your generated blocks, you might still take over the blockchain, depending on the exact implementation.

[Gavin Andresen]

https://github.com/bitcoin/bitcoin/pull/686

Testnet difficulty calculation changes, to take effect Jan 1 2012

Allow mining of min-difficulty blocks if 20 minutes have gone by without mining a regular-difficulty block.
Normal rules apply every 2016 blocks, though, so there may be a very-slow-to-confirm block at the difficulty-adjustment blocks (once per month, assuming testnet is in it's normal "difficulty too high for number of people mining it" state).

This will almost certainly cause a testnet blockchain split after Jan 1. After pulling I'll update the Testnet Faucet, I'll ask theymos if he can update the testnet block explorer bitcoind.

I didn't implement any "shun blocks from the future" or "prefer blocks with more memory-pool transactions", I want to see how well the simplest-thing-that-might-possibly-work solution works first.