Bitcoin-qt 0.8.1 going out of sync repeatedly on testnet

[matt.collier]

Hello All,

Just installed 0.8.1 on a Windows 7 64bit.  I'm running on testnet by adding the -testnet command line parameter.

The client synced initially, then I noticed some time later that it was out of sync and was needing to download approximately 38K blocks.

The first time I was going to write it off as a fluke, but it has happened several times in the past few hours.

What information can I provide to troubleshoot further?

[1714973402]

1714973402

[1714973402]

1714973402

[inglian]

I've got something like this happening, as well, where the problem seem to be a bogus block height. Twice now, letting 0.8.1 (Win7-64) run overnight on testnet, I come back to see the display showing ~80,000 blocks remaining. Debug shows the valid current testnet block height loaded, out of estimated total blocks 140,700 (!!). 

Here is a log snippet just prior to shutting down, which appears to show the bogus block height conversation:

Code:

received block 000000006d7ee37ba38b4c4226b5b635bd06faedda5273eac6e03ee647ff7a21
Committing 29 changed transactions to coin database...
SetBestChain: new best=000000006d7ee37ba38b4c4226b5b635bd06faedda5273eac6e03ee647ff7a21  height=63403  work=6294868716572339  tx=135252  date=2013-04-02 01:09:46
ProcessBlock: ACCEPTED
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
Flushing wallet.dat
Flushed wallet.dat 103ms
getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
received getdata for: block 000000006d7ee37ba38b4c4226b5b635bd06faedda5273eac6e03ee647ff7a21
Flushed 11237 addresses to peers.dat  90ms
ResendWalletTransactions()
Flushed 11237 addresses to peers.dat  68ms
Flushed 11237 addresses to peers.dat  90ms
accepted connection 75.119.251.161:46145
send version message: version 70001, blocks=63403, us=96.241.62.47:18333, them=75.119.251.161:46145, peer=75.119.251.161:46145
receive version message: version 60000, blocks=140700, us=96.241.62.47:18333, them=0.0.0.0:0, peer=75.119.251.161:46145
socket closed
disconnecting node 75.119.251.161:46145

About 20 minutes after restarting, it's imagining there are about 20K blocks over actual testnet height, again.

[deepceleron]

Someone is sending your node fake info or is testing out how much they can fork testnet with their ASIC? Are you using a release build?

The current block count is 63414 and nothing strange is going on with the network.
http://blockexplorer.com/testnet/q/getblockcount

The number of peers you connect to may affect the answer, the blocks remaining is from a majority of other nodes, so one bad actor can do some tomfoolery when there's only eight nodes and two miners.

Actually, I see a lot of that getblocks -1 to .. in my logs also, but I was never showing out of sync or wrong height. My found blocks are followed by lots of legit "received getdata"; the weird message shows up only when I wasn't 51%ing the network.

[inglian]

Yes, I am using the release 0.8.1 Win7 build. Looking in the debug log, there are two testnet IP addresses consistently claiming "blocks=140700".

This is under discussion at https://github.com/bitcoin/bitcoin/issues/2398 Final comment from gmaxwell is, "...its due to some testing phantomcircuit is doing."