Gridcoin (GRC) - first coin utilizing BOINC - Official Thread

[TribalBob]

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.

[Inrideo]

1.1.3.9-g71-prod here now Yay!

[aysyr]

First time using upgrade, but it says "Upgrade Failed. An exception occurred during a WebClient request."


Nevermind, I fixed it by changing the security settings on the \Program Files(x86)\Gridcoin folder

[Gridcoin]

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.

Cool--
I think it "might" have recovered Bob, because it takes it a long time to sort out peers as misbehaving (thats what it considers an obsolete peer) but then who knows.  I guess we'll find out after we have 24 hours of stability.

@Andrew, I havent read the doc yet, but thanks for putting it together.  I'll be reading it.

Rob H.

[Ardolafat]

What is the current block?

[traderman]

if you are not running the gridcoin-qt as Administrator, then it will crash when you try to upgrade.

First time using upgrade, but it says "Upgrade Failed. An exception occurred during a WebClient request."


Nevermind, I fixed it by changing the security settings on the \Program Files(x86)\Gridcoin folder

[Gridcoin]

First time using upgrade, but it says "Upgrade Failed. An exception occurred during a WebClient request."


Nevermind, I fixed it by changing the security settings on the \Program Files(x86)\Gridcoin folder

Oh ok, I was going to ask to see if it occurs every time, or how I can reproduce.  Im glad you figured that part out, because one other user had that problem!

Rob H.

[aysyr]

Yea that makes sense then as changing the security settings technically gave it admin rights to changes when ran.

[aysyr]

Oh, and for you guys on Cryptocoin talk, vote on which abbreviation you think we should use/keep while we aren't on an exchange yet

XGR or GRC

[TribalBob]

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:

Code:

System Error: CDB() : Can't open database file wallet.dat, error -30974

[traderman]

do -salvagewallet command

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:

Code:

System Error: CDB() : Can't open database file wallet.dat, error -30974

[TribalBob]

do -salvagewallet command

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:

Code:

System Error: CDB() : Can't open database file wallet.dat, error -30974

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.

[aysyr]

do -salvagewallet command

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:

Code:

System Error: CDB() : Can't open database file wallet.dat, error -30974

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.

I was about to post the same thing. I have one chain at 27,865 and two at 27,881 and neither have them have moved since updating. Is the chain playing catchup or something before it starts moving again?

[TribalBob]

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.

[TribalBob]

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...

[TribalBob]

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...?

[Gridcoin]

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...?

It has not been changed from litecoin's code.

The longest chain ends up being chosen.

Main.cpp 1887 (Disconnect shorter branch)

[TribalBob]

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...?

It has not been changed from litecoin's code.

The longest chain ends up being chosen.

Main.cpp 1887 (Disconnect shorter branch)

Ah ok, I see it now. Thanks!

[Gridcoin]

I feel better about this upgrade; I think we have to wait for the supermajority rule to kick in.  Now that we are almost over 51% upgraded, Im pretty sure its about to kick in, because my bad node is now counting backwards and blocks are being taken off the chain; that didnt happen yesterday.....  I think the wallet corruption was due to constant closing while the client had a lock on the file.

Rob H.

[TribalBob]

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...