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."
Topic: Bitcoin-qt 0.8.1 going out of sync repeatedly on testnet (Read 1519 times)
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.
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.
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:
About 20 minutes after restarting, it's imagining there are about 20K blocks over actual testnet height, again.
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
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.
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?
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?
Jump to: