Just a note, the fresh install of a brand new wallet just stalled out again on my laptop. I re-launched with re-scan and it's back on track, hopefully it sticks.

I wish you luck!

Alright, my wallet with all of my coins in it has now stalled out...

The other wallet which has not been tainted with coins from any of the old chains seems to be running fine so I guess I will just wipe the corrupted wallet with my earnings from the past few days and start anew back at a completely zero balance, lol...

Oh well, for SCIENCE!

Ok,

So I just renamed both of my data directories for both of my clients to "Gridcoin OLD". I re-launched the application and let it build new directories on both machines.

Both wallets started up and synced to the same block chain.

I re-started Gridcoin and used "-datadir=Gridcoin OLD" to get back into my old wallets and sent the coins from those wallets to my new primary address.

I have received the coins from both wallets and both machines are currently on the same blockchain. Now just need to see if my machines stay on the same blockchain this time, lol...

Ah ok, I see it now. Thanks!

In main.cpp I see where nBestChain is set, but I don't see any definition really as to HOW nBestChain is set. I looked through main.cpp, alert.h, alert.cpp, protocol.cpp and protocol.h, didn't see anything in those places, maybe there was some where I missed...?

Is there anywhere in the code that tells it to look for the longest blockchain (blockchain with the most confirmations for all included transactions) or how exactly does the client determine how nBestChain is defined...?

I haven't traded there in a week or two, but I have been trading there since they opened and I have never once had any kind of problem with Cryptsy.

Not saying other people are liars, just saying I've never personally had a negative experience with Cryptsy.

Alternatively, for steps 15-17 you can use:

15) cd src
16) make -f makefile.unix worldcoind USE_UPNP=
17)./worldcoind

This method is better if you use linux without a GUI, or if you just prefer to use a daemon (I prefer gnomeless Debian, so I always use daemons).

Question for the dev:

Could the fact that I have multiple projects running in BOINC that aren't in the project list be somehow placing me on a separate blockchain...?

I have been using BOINC for a while now and I am signed up to almost every project...

The stall right now is because the new client requires people to be upgraded to the latest version so anyone who has not yet seen this thread is pretty much still mining on an out of date blockchain, there are probably only a handful of us at the moment who are on the latest version and the difficulty is still set from the old chain so the chain thinks there is a whole network f miners when there is actually only a handful of us.

It will start moving again either when we reach the next re-target or when the other miners catch up with their upgrades.

That seems to have done the trick, thanks m8! Forgot about the "-salvagewallet" flag (never had to use it).


So, now both clients are running, both clients are the latest version (version 30) both say they are synced, but they are on completely different blockchains.

One block chain is currently 27,865 blocks long with a difficulty of 1.17921727 and the other is on a blockchain that is 27,881 blocks long with a difficulty of 1.44197764.

Ok, I have one client fully updated and running fine, but when I try to re-install the other from the latest MSI using my old wallet.dat I am receiving:

Ok, I tried "upgrade" on both of my clients (which were both already using version 29).

The upgrades said that they completed successfully but when the clients restarted each client was still showing a different hash number for the current block. Attempting a clean re-install from the latest MSI to see if that fixes the issue.

I can confirm that I just had the problem on one of my clients about an hour ago. Launching with "-rescan" fixes the issue temporarily (at least for me anyway) but the problem is definitely recurring.

For those having trouble with sync issues on "stalled" wallets, before deleting the stuff in your roaming folder, try the following from a command prompt (windows users):

1) cd c:\Program Files (x86)\Gridcoin
2) gridcoin-qt.exe -rescan

This is consistently fixing my sync/stalled client issues and is essentially the same as deleting the files in your roaming folder as it forces the client to rescan the block chain.

But I still opt for the global upgrade, better to do it now than to continue letting new users jump on a faulty client...

signed

Hello.

Type the following from a command line:

1) apt-get update
2) apt-get install install qt4-dev-tools libqt4-dev libqt4-core libqt4-gui
3) apt-get update
4) apt-get install build-essential
5) apt-get install libssl-dev
6) apt-get install libdb4.8-dev
7) apt-get install libdb++-dev
apt-get install libqrencode-dev
9) apt-get install libboost1.48-all-dev
10) apt-get update
11) apt-get install git
12) apt-get update
13) git clone https://github.com/worldcoinproject/Worldcoin
14) cd Worldcoin
15) qmake "USE_UPNP=-"
16) make
17) ./worldcoin-qt

I have done clean re-installs of the latest client (version 29) multiple times and I am still having sync issues at times. See my post above as I believe I know the reason for this.

I have been experiencing this as well, usually after I restart it gets stuck at N hours behind and won't sync any further but that is easily fixed by launching with "-rescan".

But like you I am also experiencing where I come back to see 3 or 4 accepted blocks and then the sync gets stuck at a place and I have to restart which is when I get stuck at N hours behind and the coins are no longer in my wallet when I get synced back onto the correct blockchain.

I think what is happening is that those blocks are being orphaned or perhaps we are ending up on a forked chain and then we somehow get stuck when the client is trying to find it's way back onto the correct chain.

Is anyone else having trouble with their client occasionally stalling out...?

I woke up today to find my miner had been hashing away on the same block for more than 4 hours because one of my clients had stalled and was pretty far behind in the actual block count even though the client said it was synced.

What's really weird is that my other client (I have two pc's and one runs cgminer on load balance between the two clients) was still perfectly synced but the miner was not receiving new block notifications from the synced client either.

Anyone else experiencing anything similar...?

Hello,

Try re-launching with "cgminer.exe --scrypt" instead of "cgminer.exe -scrypt".

Need to have that extra "-".