Quote from: DarkEmi on February 03, 2015, 07:39:40 AM

Yes we had exactly the same issue. We had so many different issue that I am unsure now how we solved this one, I think that we just switched onto btcdrake bitcoind. We might also have used a bootstrap database afterwards.

We were blocked at block 280xxx

But we did not run the tests from bitcoin core tests, of that I am 100% sure.

It indeed seems like a recent issue that has been affecting a lot of people and its probably unrelated to counterparty, its unliky for us that it struct us several times when we were working with XCP. It might have been because we made a migration from ubuntu 12 to 14 and thus upgraded all our library, ending in the possible open SSL incompatibility

I think this had to do with the 0.9.2 jmcorgan build. On a few instances I had similar issues with it hanging on block 28xxxx. It had something to do with the sequence of running, downloading the blocks, addrindex and reindex. And at times if I had to stop it half way and came back to run it again it would fail. The latest bitcore addrindex 0.10.x builds though appears to have solved those issues.

The issue appears to be Not counterparty related, but the addrindex bitcore builds failing to parse all of the blocks. What I have found though is as long as you have at least one good instance of block data already indexed, just copy that over. Works like a charm. And on a another note, with the additional load of address indexing I would recommend doing this with a SSD drive (at least for the initial run)