Thanks for the DB download.
I've been mining coins for quite a long time and have seen some pretty shitty forks, which usually result in the developers having to release a client that actually kills the bad forks. I don't understand why developers and people say 'just let it sort itself out', meanwhile countless users of the coin risk losing fuck tons and mining time by continuing to use essentially a broken coin?
Developers should be on top of this shit. They should immediately release a client that kills the old forks if it doesn't clear itself up in 3-6 hours. We've had this forking issues since the 1.2.1 release if I'm not mistaken, which happened on... friday? From what I understand, it's not hard to kill old forks either with a new client.
Forks are like a slow poison that work their way through a coin and really mess things up. If there is an exchange as big as Poloniex still on the wrong fork, there is definitely something wrong, regardless of how good the coin is. Tons of people exchange with poloniex and if they see their transactions going through, it'll perpetuate the circle.
There is essentially six pages of posts here trying to find ways to fix the fork, work on the fork, and eventually culminated in a 'community fix', which is transplanting someone elses DB to your computer, which you should never need to do if everything is working alright. Is releasing a new version of the wallet really 'that' bad compared to having people possibly sit on a fork for god knows how long?
I know, I know, forks happen, but pro-active development could really limit their impact.
1.2.1 was the fix. It was released 6 days ago.
1.2.1 won't sync to the 1.2.0 fork, and 1.2.0 won't sync to the 1.2.1 fork, however 1.2.1 can get stuck for a little while at the fork point if it can't find the 1.2.1 fork right away due to all the 1.2.0 spam.
The only problem in play right now is the number of 1.2.0 clients around and amount of hashrate still on 1.2.0 keeping that fork running and widely available. Sure an update could be released to blacklist the 1.2.0 fork, but the 1.2.0 fork fails validation in 1.2.1 anyway, so it wouldn't change anything. The only fix is having a larger percent of the network on 1.2.1, and time and publicity are the only things that help that out.
Personally I've yet to see any significant issues getting onto the correct fork when using 1.2.1, although it depends a lot on which/how many peers you are connected to. I had 4 instances of 1.2.1 running from separate locations from before the fork, and they all followed onto the correct one without issue. I've also synced up to date in 1.2.1 from old blockchain copies I had, and from fully synced 1.2.0 from the bad fork, and nothing took more than a few minutes to figure out which the correct chain was.
things worked fine for my wallets too, but at 59800 something broke, and i went on a bad fork, i tried to restart many many times, and waited for hours. my wallets were stuck on the shorter chain, and there were these notifications of exceptions as shown previously. i didn't have the experience that my 1.2.1s went to the longer chain by themselves in any kind of hurry.
after having downloaded the right fork things worked for a while again, but right now, my wallets seem to post an error every 15 seconds, along the lines of :
2015-01-26 10:46:15 INFO: tx with id -1019205954960601549 found
2015-01-26 10:46:15 INFO: get timestamp for tx with id -1019205954960601549 found
nxt.at.AT_Exception: Calculated md5 and recieved md5 are not matching
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
i am working on block 60018 on all 3 wallets (all 3 showing above info message, with various intervals from seconds to minutes)
basetarget 2027904 height 60018 indicates i am on the right chain right now i would assume, but i fear we might have forked again around 60017 +/- as the last fork started with a similar error beginning to show on the bad fork.
Must admit that i *am* running a version i compiled myself, so i might have done something wrong in the build, in which case i should be the only one seeing above error. When i'm back from work tonight, i'll try to use the original 1.2.1 and see if that makes a difference.