The idea of the second daemon is that it can be stopped momentarily for the purposes of snapshotting without disrupting the pool. Yeah, that is indeed the way of doing it. I replied without really thinking it through  |
|
|
|
try to restart with the -rescan switch
I try (however I heve a fresh wallet), but not seems to change. In log I see: partner 115.238.164.208:4177 using obsolete version 60006; disconnecting as I use the -connect=188.226.240.91 with peers deleted, I could expect it will only une the given address for node, and not try others (it seems instead it connects to others) I assume the connection is an incoming one, maybe someone has your ip address in their config, I just checked on 3 nodes and I didn't get the request for that IP. If you are on linux (i have ubuntu) I can send you a link to a copy of my blk0001.dat and blkindex.dat later. or you can setup a different node (with a different IP) and try to sync from there, then copy over to your pool. |
|
|
|
ok, bootstrap finish but still blocked at the same point even using -connect=188.226.240.91
However in log (I cannot copy from here, need to attend this night), there is an exception in libboost_thread about ProcessMessage: 'CDataStream::read() : end of data' and something that seems to be a message short of declared data length.
Else there are some ERROR: CheckProofOfStake(): INFO: check kernel failed for block xxxxxx hashProof=0000000000000000..
I had that error, If I remember it did sort it out by itself, did you try a shutdown and a restart? yes, but it manifest the same behaviour. however, as yesterday night the pc wallet goes ahead from the same stopping point (I cannot check log as it was too late), I will copy (as soon as I will be at home) blk and index from it to pool to have a situation more advanced to use. try to restart with the -rescan switch |
|
|
|
ok, bootstrap finish but still blocked at the same point even using -connect=188.226.240.91
However in log (I cannot copy from here, need to attend this night), there is an exception in libboost_thread about ProcessMessage: 'CDataStream::read() : end of data' and something that seems to be a message short of declared data length.
Else there are some ERROR: CheckProofOfStake(): INFO: check kernel failed for block xxxxxx hashProof=0000000000000000..
I had that error, If I remember it did sort it out by itself, did you try a shutdown and a restart? |
|
|
|
Probably wouldn't be too much trouble to have a second daemon running, solely for backup purposes. That way you have a valid db to snapshot AND zero downtime for your pool daemon.
that's actually a good option too. I haven't test it on the same machine yet, but you could ./growthcoind -listen=0 -datadir=/some/backup/folder this would recreate a new blockchain directory in /some/backup/folder and run alongside your primary deamon EDIT: the only issue I might see with this option is in the case of a fork.. if that second daemon is also stuck on the fork, it wont be much of a help. That's why having like 2 set of snapshots would help in that case. You'd just have to sync from before the fork |
|
|
|
ok, just an heads up, you should keep a working snapshot of your blk0001.dat and blkindex.dat at regular interval. If for some reason you get on a fork or get a corrupted db, you could restore that version.
It will be faster than bootstrapping or redownloading the whole block chain from the beginning.
Yes, I do this for over a month as I have the problem that a regular coind stop in pool (for server mainternance) has 80% of probability to get the index corrupeted, so I make the pool up in 5 minutes by using the old saved blk/index and downloading the missing blocks. Unfortunately the last save was before the coin fork, so I whould like to start from a more recent situation where the main fork was missed. Can the snapshot of blk and blkindex make even if daemon is running? If so I can automatizate the operation every days without the needs of stopping daemon. It is not safe to do it while the daemon is running, you could end up with a corrupted copy. you could still automated it with the command ./growthcoind stop && cp blkindex.dat blkindex.snapshot && cp blk0001.dat blk0001.snapshot && ./growthcoind you would have some downtime but it would be minimal it takes about 2 minutes to copy everything. note that I didn't test this line personnaly but I think it should work. |
|
|
|
I restarted this morning a new bootstrap phase and it is not yet finished.
If it blocks as before, I will stop it and use that switch
ok, just an heads up, you should keep a working snapshot of your blk0001.dat and blkindex.dat at regular interval. If for some reason you get on a fork or get a corrupted db, you could restore that version. It will be faster than bootstrapping or redownloading the whole block chain from the beginning. Note that some people have reported that bootstrap sometimes fail. I personally never had any problems with it though. so keep that in mind. lastly, if this fails again, try do download from scratch the block chain. but try to stop the client at every 100k blocks or so (making a copy of blk0001.dat and blkindex.dat) and then continue the process. it will become handy if you ever get stuck again somewhere in that process. other than that, the process should run smoothly. I personally tried updating the client that wasn't on a fork and it worked successfully, I have bootstrapped 2 nodes that got stuck on a fork and that too worked perfectly well. and lastly I have resynced 1 node from scratch, it took about than 1.5 day (but I had only a 1 core CPU on that one so it can be quicker for better system). hope you get back online quickly |
|
|
|
It seems now that in pc the wallet it is going on but extremely slowing.
Maybe the pool still offline for this morning
I just opened the wallet and synced the last two days and it caught up quick. Just restart the client if it gets stuck on a block. In pool it downloads only one more block after 7h of it was restarted. I wil ltry another restart.. delete the peers.dat file (I think you already did that) and then try to start using the swtich -connect=188.226.240.91 |
|
|
|
I am getting this error when I am trying to build the windows-qt on ubuntu, with VM.
Starting target
Checking if target is up.
Preparing build environment
qt-win32-4.7.4-gitian.zip 100% 21MB 21.1MB/s 00:01
boost-win32-1.49.0-gitian2.zip 100% 17MB 17.3MB/s 00:01
growthcoin-deps-1.2.0.zip 100% 4050KB 4.0MB/s 00:00
growthcoin.zip 100% 58MB 29.2MB/s 00:02
Updating apt-get repository (log in var/install.log)
Installing additional packages (log in var/install.log)
Grabbing package manifest
Creating build script (var/build-script)
Running build script (log in var/build.log)
bin/gbuild:21:in `system!': failed to run on-target setarch i386 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError)
from bin/gbuild:118:in `build_one_configuration'
from bin/gbuild:235
from bin/gbuild:230:in `each'
from bin/gbuild:230
from bin/gbuild:228:in `each'
from bin/gbuild:228
So I'm currently looking in the "gitian-win32.yml" and comparing it with other wallet that works to build, to see if I can find the error there.
Also going to look in build script (var/build-script) & (log in var/build.log)
I was thinking I could build the windows wallet, when it is needed, but it doesn't seem to work atm.
Haven't had time to play with the gitian builder. I'm not even sure these files are configured properly, if you make any changes and you make it work, let me know  |
|
|
|
Same here, followed your link and it shows:
"version" : "v1.3.0.0-beta",
"protocolversion" : 60007,
"walletversion" : 60000,
also, the network shouldn't reject blocks from protocol version 60007, so if you can share your debug.log when the rejection occcurs, I would like to take a look at it. thanks Your 1.3.0.0 github version does seems to stake, now up to 35 confirms, didn't get that with the old 1.3.0.0 dropbox version. Don't know if its relevant, but I remember it showed networkweight of 5000 while my walletweight alone is 17k+ The github 1.3.0.0 version shows more realistic numbers: wallet 17k and networkweight 57065.4 Will try the new wallet from presstab now. BTW the new wallet looks great! :-) ok, thanks for the heads up, orphans are normal when staking, it is still based on luck so that might just have been the issue. Glad to know it's working then netstakeweight and your wallet weight are surprisingly not related. They are 2 metrics calculated differently. while your wallet weight is based on your blocks age, the netstakeweight is based on the last few blocks of stake generated. hope this makes it a little bit more sense New wallet working correctly. Shows version: "version" : "v1.3.0.1-beta", "protocolversion" : 70001, "walletversion" : 60000, And stakes without orphans, already 6 pos stakes complete, 50+ confirms! I did lose all my old stakes of tonight, but i suppose it was because i was on the wrong fork as well as noise23. My wallet now shows: getblockhash 593090 - 000000011be8c3e99e0baffb7100161e7568a5cf787cbbe7d6045678b40de8b5 But with my old stakes (those who disappeared), it showed getblockhash 593090 - 3c56abc5208295cbc2c6cfa27d5ff282d1554a94b4e5bd054b8c661f66fcb099 I guess getblockhash 593090 - 000000011be8c3e99e0baffb7100161e7568a5cf787cbbe7d6045678b40de8b5 it the current and correct chain, am i correct? BTW your explanation of walletweight i understand, i guess that the comparison of both weights it is also the way the "next stake in xxx days" message is calculated. BTW2....... Are the download links on the grw site and github updated? This to prevent new users from installing the old client. Thanks for all the replies, I hope my information is perceived as helpful and not as complaining, you and all others are doing a great job! excellent news that everything is staking away Losing those Stakes is not that of a big deal since they will stake again on the correct chain. getblockhash 593090 - 000000011be8c3e99e0baffb7100161e7568a5cf787cbbe7d6045678b40de8b5 is indeed on the right chain. You are good there. Wallet weight is based on your coin age. but presently, this information is wrong since no coins will stake before about 8.8 days of age. It will be necessary to create a hard fork and make changes to the stake modifier in order to get the desired 5 days of minimum age. The link on the site (I assume http://growthco.in) I can't change, the link on the github has been updated for the pre-release download. I think it's neilh that provides the website, I'll make sure he gets the info to update the version on the site |
|
|
|
I feel like I have to talk about something. I understand every coins taken a beating in July and they have, market sentiment seems negative at the moment, perfectly normal in cyclical markets.
Still something feels forced. Consistent looks at the Depth chart show Buy support is ALWAYS larger than sell support yet there's consistent~5-29000k dumps every day. Each dump waits for support to build and purposefully crashes through that support to reach a new low. In the last week alone we have seen over 230,000HBN dumped. The issue is that who ever is dumping isn't trying to maximise individual profit at all, it seems they are either:
a,Aiming at HBN hitting a certain price,
b, trying to crash the market,
or C, there's lots of medium stake holders leaving the market which are panicking and stupid frantically hitting the sell button.
We all know these are amazing times to buy in. I would of killed for these price just a month ago. Why the exodus? And more importantly who's buying in? If we have fresh community members, please introduce yourselves.
I have no idea what's going on, but I love your reasoning on this. If it's true that big players are playing the markets, then they are trying to enter at a low, low price and when they bought what they were looking for, we might be in for a nice swing up. if people are panicking, I wouldn't understand why? since I didn't hear any particular negative news lately. either way, only time will tell! HBN at around 5k sat is something I haven't seen for a long time! I wish I had more spare BTC to buy some more at these prices  |
|
|
|
I still like this coin... even though it's never staked. My info says: Stake Weight....... 14474 Network Weight.... 69070 You have a 50% chance of producing a stake next 47 minutes. Now this has been an hour or less at least 18-24 hours... So if each hour is a 50/50 coin flip... I have just flipped 24 heads in a row to not stake. Based on the coin info my chances of NOT STAKING would be about 1 in 16,000,000... So these numbers are off by SEVERAL ORDERS OF MAGNITUDE. But I still like this coin  If my understanding is correct, coins received prior to July 4th, still needs 30 days before they stake. Only new transactions after the July 4th cutoff, will be eligible for staking after just 15 days this is supposed to be accurate, I guess we will know for sure in about 5 days, around July 19th, the first Tx would have the minimum age for stake. |
|
|
|
Same here, followed your link and it shows:
"version" : "v1.3.0.0-beta",
"protocolversion" : 60007,
"walletversion" : 60000,
also, the network shouldn't reject blocks from protocol version 60007, so if you can share your debug.log when the rejection occcurs, I would like to take a look at it. thanks Your 1.3.0.0 github version does seems to stake, now up to 35 confirms, didn't get that with the old 1.3.0.0 dropbox version. Don't know if its relevant, but I remember it showed networkweight of 5000 while my walletweight alone is 17k+ The github 1.3.0.0 version shows more realistic numbers: wallet 17k and networkweight 57065.4 Will try the new wallet from presstab now. BTW the new wallet looks great! :-) ok, thanks for the heads up, orphans are normal when staking, it is still based on luck so that might just have been the issue. Glad to know it's working then netstakeweight and your wallet weight are surprisingly not related. They are 2 metrics calculated differently. while your wallet weight is based on your blocks age, the netstakeweight is based on the last few blocks of stake generated. hope this makes it a little bit more sense |
|
|
|
It seems like we just got another fork -
right now grw.acidpool.com and grw.blockx.info are at 593090
getblockhash 593090
000000011be8c3e99e0baffb7100161e7568a5cf787cbbe7d6045678b40de8b5
my home pc win wallet and grw.multi-pool.info are at 593107
from my pc wallet -
getblockhash 593090
3c56abc5208295cbc2c6cfa27d5ff282d1554a94b4e5bd054b8c661f66fcb099
this should not be a problem, the block your home pc and multi-pool are on is a PoS block, if that chains wins to be the longest, it should reorganize and sync for all the network. But I'll still keep an eye on it |
|
|
|
thanks for the quick reply |
|
|
|
Same here, followed your link and it shows:
"version" : "v1.3.0.0-beta",
"protocolversion" : 60007,
"walletversion" : 60000,
also, the network shouldn't reject blocks from protocol version 60007, so if you can share your debug.log when the rejection occcurs, I would like to take a look at it. thanks |
|
|
|
|
you guys are right,
I'm going to ask Presstab to build the Qt client for windows. I'm on a Mac and can't do it since my virtualbox is not configured properly yet.
sorry about that
|
|
|
|
Strange things happening.... I'm on the right blockchain, i used the getblockhash command. Thanks Unick! Current shows: getblockhash 592973 - 0000000cd886aa4eb844f5354e21cdc3a2e9af26cea2f18c7db09e904ca31aa8 Using the betaclient from here: https://www.dropbox.com/s/5xkk8npt6enabuk/GrowthCoin-Qt.zip"version" : "v1.3.0.0-beta", "protocolversion" : 60007, "walletversion" : 60000, But I'm only getting orphans when staking. Some go up to 10 confirmations and then get rejected. this is the wrong version you should have protocol 70001 please download the pre-release version (1.3.1.0) from this link https://github.com/iamunick/growthcoin/releasesthe version you should read in your client is 1.3.0.1 I just grabbed the Qt from the github link, and I get "version" : "v1.3.0.0-beta",
"protocolversion" : 60007,
"walletversion" : 60001, Hum, let me check then. it's supposed to be protocol 70001 |
|
|
|
Strange things happening.... I'm on the right blockchain, i used the getblockhash command. Thanks Unick! Current shows: getblockhash 592973 - 0000000cd886aa4eb844f5354e21cdc3a2e9af26cea2f18c7db09e904ca31aa8 Using the betaclient from here: https://www.dropbox.com/s/5xkk8npt6enabuk/GrowthCoin-Qt.zip"version" : "v1.3.0.0-beta", "protocolversion" : 60007, "walletversion" : 60000, But I'm only getting orphans when staking. Some go up to 10 confirmations and then get rejected. this is the wrong version you should have protocol 70001 please download the pre-release version (1.3.1.0) from this link https://github.com/iamunick/growthcoin/releasesthe version you should read in your client is 1.3.0.1 |
|
|
|
|
Show Posts
