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.
Topic: Time for another testnet reset? (Read 4126 times)
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.
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.
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.
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.
to get extra coins?
This is the testnet we're talking about… coins on the testnet have no value… 
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.
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.
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?
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.
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?
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!).
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.
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!).
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
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!).
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!).
Three proposed changes to simulate testnet to what the Future for Bitcoin will look like.
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.
- 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.
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. In my case, it was about a month of multi-GH mining effort that just went up in a puff of smoke.
What were you testing that you needed to dedicate about a month of multi-GH mining effort?
the goal of the testnet is to be able to use an alternative blockchain with the same binary.
the current approach creates the issue when you want to switch your tests to a different block chain, yet not to the expensive one
first of all, you need to modify the client itself - second, you mess with other people's objectives by doing this.
so an external config file, defining the testchain, would be much less intrusive and future friendly.
just replace the "-testnet" switch with an optional config file that would define the genesis block.
the current approach creates the issue when you want to switch your tests to a different block chain, yet not to the expensive one
first of all, you need to modify the client itself - second, you mess with other people's objectives by doing this.
so an external config file, defining the testchain, would be much less intrusive and future friendly.
just replace the "-testnet" switch with an optional config file that would define the genesis block.
Hey, don't destroy all my testnet coins a second time!
The only reason people don't consistently mine on testnet was because of the reset the first time. People were mining on testnet, legitimately, and blocks were semi-regular. But then the first reset came in, and all that effort was destroyed. In my case, it was about a month of multi-GH mining effort that just went up in a puff of smoke. The first time, the reason was apparently that the difficulty was too high for low-end mining testing, plus, and this is IMO, people who weren't in on the testnet OTC market didn't like to see testnet coins for sale (which was making testnet coins a competing currency.)
Complaining about people not consistently mining on testnet this time around is kind of irritating given the first testnet reset was reset even in the face of opposition from people who were actually using it (and consistently mining in it.)
The only reason people don't consistently mine on testnet was because of the reset the first time. People were mining on testnet, legitimately, and blocks were semi-regular. But then the first reset came in, and all that effort was destroyed. In my case, it was about a month of multi-GH mining effort that just went up in a puff of smoke. The first time, the reason was apparently that the difficulty was too high for low-end mining testing, plus, and this is IMO, people who weren't in on the testnet OTC market didn't like to see testnet coins for sale (which was making testnet coins a competing currency.)
Complaining about people not consistently mining on testnet this time around is kind of irritating given the first testnet reset was reset even in the face of opposition from people who were actually using it (and consistently mining in it.)
I see a philosophical dilemma here. The testnet was never intended to produce anything of value. Strictly speaking, it's used for "offline" testing in a "realistic" environment. From that perspective, the devs are only interested in what's best for the developer community in terms of what to do with the testnet.
On the other hand, if a clique of people latch onto the testnet and its coins, and start treating it as if it has value -- well then it's no different than BTC itself, and the devs should take into account the fact that they are about to destroy something "of value." As such, a lot of people--those who perceive value in the testnet coins--would be peeved at a testnet reset...
So where does reality fit into all of this? Well, the developers need a testing network that isn't the real network. I think it had been made clear before that was the purpose of the testnet, so assigning value to it was a "mistake" of that clique, not the developers "destroying" it. We shouldn't be forcing the devs to go out of their way to create a Testnet2 just to accommodate the clique of people who attached themselves to the first one.
And for the record, I'm not so much complaining about people not mining consistently... it's that no one is mining right now, and I would do it myself if the difficulty wasn't so high. But, I think it's silly for me spend 24 hours of CPU compute time just to mine one testnet block, which doesn't have any value to me...
Hey, don't destroy all my testnet coins a second time!
The only reason people don't consistently mine on testnet was because of the reset the first time. People were mining on testnet, legitimately, and blocks were semi-regular. But then the first reset came in, and all that effort was destroyed. In my case, it was about a month of multi-GH mining effort that just went up in a puff of smoke. The first time, the reason was apparently that the difficulty was too high for low-end mining testing, plus, and this is IMO, people who weren't in on the testnet OTC market didn't like to see testnet coins for sale (which was making testnet coins a competing currency.)
Complaining about people not consistently mining on testnet this time around is kind of irritating given the first testnet reset was reset even in the face of opposition from people who were actually using it (and consistently mining in it.)
ಠ_ಠ
The only reason people don't consistently mine on testnet was because of the reset the first time. People were mining on testnet, legitimately, and blocks were semi-regular. But then the first reset came in, and all that effort was destroyed. In my case, it was about a month of multi-GH mining effort that just went up in a puff of smoke. The first time, the reason was apparently that the difficulty was too high for low-end mining testing, plus, and this is IMO, people who weren't in on the testnet OTC market didn't like to see testnet coins for sale (which was making testnet coins a competing currency.)
Complaining about people not consistently mining on testnet this time around is kind of irritating given the first testnet reset was reset even in the face of opposition from people who were actually using it (and consistently mining in it.)
ಠ_ಠ
Why don't you just make the genesis block/tcp port/irc channe/whatever configurable?
I.e. via a config file.
Then with one binary there could be many testnets described by the config file and everybody would choose the one he needs.
Or start his own one, when he needs.
I.e. via a config file.
Then with one binary there could be many testnets described by the config file and everybody would choose the one he needs.
Or start his own one, when he needs.
http://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/
Why don't you just make the genesis block/tcp port/irc channe/whatever configurable?
I.e. via a config file.
Then with one binary there could be many testnets described by the config file and everybody would choose the one he needs.
Or start his own one, when he needs.
I.e. via a config file.
Then with one binary there could be many testnets described by the config file and everybody would choose the one he needs.
Or start his own one, when he needs.
Jump to: