|
Title: Testnet specific code being exploited Post by: deepceleron on November 02, 2014, 10:35:47 AM I saw this potential problem a while ago:
A feature of testnet could be used as a difficulty-amplification attack. I've just done it for fun and profit. "In addition, if no block has been found in 20 minutes, the difficulty automatically resets back to the minimum for a single block, after which it returns to its previous value." while the last block was full difficulty: while the local time isn't more than two hours ahead of network time Set local clock forward 20 minutes from last block, mine difficulty 1 block, This could drive difficulty seven times higher than actual hashrate. On the plus side, easy 50 BTC if you can't ASIC mine. I made the same 300 testBTC in 5 minutes as I did in two days of GPU. One for the bug pile: getmininginfo displays the last block's difficulty, not the targeted difficulty. On testnet it will often display "difficulty: 1" from this keep-blocks-a-rollin' feature. Well, now someone has scripted a time-playing attack and is using it to 7x the difficulty and monopolize non-PoW mining: http://we.lovebitco.in/img/testnettimewarp.png The problem is that this basically warps testnet coinmaking. The miner not only makes all the timewarp difficulty 1s allowed, they also sit on the highest time allowed and publish a block find the second the network time allows it. This can DoS any developers looking to test specific mining features. The simple way to combat this is if miners also move their clocks ahead two hours to prevent the mining of the extra blocks allowed by the time margin. If miners just set their computer time ahead though (which is published P2P), we will have a testnet that drifts into the future. Miners could also ignore difficulty 1 and build a higher difficulty chain using real PoW, orphaning & doublespending etc. This has pushed testnet up to difficulty 700+. As there is one block find every 20 minutes + 7 block finds for every proof-of-work, the difficulty will continue to increase, with the upper bound approaching around one block actually mined per difficulty evaluation period. Also the bug below. Looks like the "keep testnet mining" difficulty 1 code needs to be revisited: I reset the testnet difficulty to 1 using a bug with the testnet-specific difficulty code. The prior difficulty was ridiculous and testnet doesn't reduce in difficulty when hashrate drops the way we would expect it to reflect actual full-difficulty hashrate. Enjoy the coin bonanza. The difficulty is currently up to 1024 and will be increasing at 400% per retarget for quite a while. Title: Re: Testnet specific code being exploited Post by: Gavin Andresen on November 03, 2014, 08:55:10 PM Looks like the "keep testnet mining" difficulty 1 code needs to be revisited: "patches welcome" In general: "meh" -- most testing is done in -regtest mode in a more controlled environment these days. Title: Re: Testnet specific code being exploited Post by: gmaxwell on November 04, 2014, 06:10:18 AM The behaviour in testnet is intentionally insecure. Things like the difficulty reset are intentionally tested in the chan and weren't a surprise when you posted about them previously (go look in the chain, I demonstrated it right before or after the timewarp in the early blocks).
The reality is that it's a little network and it's easy to screw with regardless of what the rules are. The general chaos there is good for testing some things, not others, feel free to use regtest or fork off testnet at some prior point (IIRC I even put a 100k TNBTC (IIRC) fee in some block for nice testing if you fork from there). |
