Bitcoin Forum
December 10, 2016, 05:05:00 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Testnet chain split scheduled for Feb 15  (Read 1276 times)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
January 31, 2012, 07:06:06 PM
 #1

FYI: I pulled:
  https://github.com/bitcoin/bitcoin/pull/686

... which will likely result in a testnet blockchain split on February 15'th. I hadn't pulled before because I was busy with other things. The testnet faucet bitcoind will be updated in the next day or two.

See this thread for the design discussion.

How often do you get the chance to work on a potentially world-changing project?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
deepceleron
Legendary
*
Offline Offline

Activity: 1470



View Profile WWW
January 31, 2012, 09:42:24 PM
 #2

Maybe too late to comment, since it's already been pulled... As a test platform, the coding for and operation of testnet should have as few differences as possible from the mainnet code. We note that others identified bugs introduced in proposed testnet code, and we also wouldn't want it to be harder to identify issues using testnet because of weirdness with the new rules.

It seems the issues to be addressed are:

- High hashrate miner can leave difficulty too high,
- Scarcity of coins makes it hard to test without getting test coins from someone else

I would propose that this could be improved by one change - capping the difficulty somewhere around 128 (it is currently 8.9). Even if the blockchain says it is higher, miner would use and accept the maximum as the target if it is testnet. At the highest difficulty, this would allow a single GPU miner to generate a block in 1-3 hours.

Another option, maybe too easy or too far out there - permanently set the testnet target? Just exploring ideas that would take minimum changes to code as long as we are resetting. Maybe even get rid of legacy testnet code like 1/2 difficulty and default port (testing requires manually setting test port).

The only problem remaining exists both now and after this change - malicious attacks are too easy to "test" - an attacker can monopolize testnet mining and interrupt transactions. The only solution to to this would be to defend the test blockchain with a merged mining pool or such. However such a situation also exists in real Bitcoin too - do we not want to be able to see how testnet responds to takeover attacks?


Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!