Bitcoin-qt 0.6.3 not downloading past Block 192528 [+Armory]

[XertroV]

Using Bitcoin-Qt (and bitcoind) v0.6.3 from the PPA [Ubuntu 12.04 x64].
Have tried launching a freshly compiled Bitcoin-qt also.

Despite this and a -rescan, the client doesn't seem to want to download past blk 192528

I use Bitcoin-qt just to downloads blocks with an unused wallet.dat. I run it with Armory 0.81-alpha attached.

Strangely, Armory seems to be downloading new blocks fine. It also registers new transactions (after 192528). The height currently is 192885 which matches blockchain.info.
However, from Armory I cannot broadcast transactions to the network - but only from select wallets. I presume this is because Armory tells my client that a transaction is taking place many blocks ahead (in terms of transaction balances) of where the official client thinks it could be; I cannot send coins from an address which has only received coins AFTER block 192528, however, an address which has held some value since at least block 192528 will generate an accepted transaction.

Resources I've found prior to this:
https://bitcointalk.org/index.php?topic=78307.0 [happened april 23ish]
https://github.com/bitcoin/bitcoin/pull/1196 [apparently fixed the issue]

Anyone have any ideas? I'll try not re-downloading the blockchain for a little while so any debugging/info gathering type thing needing to be done can be.

/dev/sda6                53G   18G   33G  35% /

[Pieter Wuille]

Could you:

• Turn on detachdb (start with -detachdb, or check the relevant option in Bitcoin-Qt)
• Shutdown bitcoin
• Make a backup of your entire datadir, excluding the wallet
• Make that backup available somewhere, where I can access it

?

We've been hearing reports like this for a while now, but never able to actually see the problem occurring or reproducing it ourself.

[Kitemike]

Mine is stuck on 192800.  This wallet only has .007 btc in it and I'd be happy to zip it up and send the whole directory to anyone that has the resources to troubleshoot this problem.  I'll just start over with a new wallet.

...Never mind.  After two hours is suddenly caught up the last blocks.

[Pieter Wuille]

If you're really stuck, I'd very much like to have a look at it.

But make sure:

• You're not out of disk space
• You are really connected to some other peers
• Your internet connection is stable
• You are really stuck, and this does not change after letting the client be connected for let's say an hour

[Kitemike]

There was a message in the progress bar area that said something about either me or a node needing to upgrade.  I am already running 6.3 and had 8 active connection.  It must have been Bernanke trying out his new firewall.  Mine finally did catch up.

[deepceleron]

I have Bitcoin 0.6.3-beta on Win7 x64 that is 1679 blocks behind (1522 after typing this post), it was seeded with the same 189238 blockchain posted here and has been through a few catch-up restarts as it's not always running. It's getting about a block a second off the p2p network so it should be caught up in half an hour, which I will report. I would assume if mainline win builds had a problem we would hear about it more though.

The debug.log and db.log files may have some indication of what Bitcoin is doing besides updating the blockchain. Previously such hangs have indicated blockchain file db corruption.

Update: up to date, no problems.

[XertroV]

Could you:

• Turn on detachdb (start with -detachdb, or check the relevant option in Bitcoin-Qt)
• Shutdown bitcoin
• Make a backup of your entire datadir, excluding the wallet
• Make that backup available somewhere, where I can access it

?

We've been hearing reports like this for a while now, but never able to actually see the problem occurring or reproducing it ourself.

• Detachdb is always on for me (so I can copy the blockchain more easily)
• Backing up now, will PM you with a link (so I don't run through all the bandwidth); if anyone else needs a link please let me know [or maybe torrents would be a better idea; I'm on a 100mbs connection here]

Update: PM'd

Update2: I noticed that Armory stayed up to day until I started using a new datadir (mv'd old one and set up a symlink to make future experiments easier). It now registers from as far as bitcoind has downloaded. I ran into an issue where new blockchains would not have a blkindex.dat and bitcoind/-qt would try and download from block0 but would APPEND new blocks to the blk00002.dat. So even though blk00001/2.dat existed, they were ignored. Didn't get a crash or exception so I presume that it's not a libdb++ issue.

The point of all this is it might be the case that bitcoind/-qt WAS downloading new blocks, but just not processing them! Maybe.

[XertroV]

Updates: I've run another bitcoind (with -datadir) to a fresh directory, and I this bitcoind downloaded all the blocks without any fuss. This is nice since nightlies weren't working too well for some reason.

If anyone else has this problem this is a potential solution.

In the new dir you have to setup bitcoin.conf with port= and rpcport= [pick two numbers other than 8332 and 8333] set to avoid port collisions. Then also put in an addnode to your already running client:

rpcport=9998
port=9999
addnode=127.0.0.1

That way it will download the blockchain quite fast (faster than I get on 100mbit/s internet; though I've got an SSD too) and will be happy to download past the stuck block.