Topic: [RE-ANN] GrowthCoin PoW/PoS - 100% per year - Version 1.3.0.1 - page 31. (Read 66388 times)
where to download the newest window wallet?
Hey guys, could someone please build the latest version for mac for me?
There you go, https://github.com/iamunick/growthcoin/releases/download/1.3.1.0/growthcoin-1.3.0.1-macosx.dmg
Thanks a lot appreciate it
My old backup works perfectly. Pool repristinate with wrong blocks still confirmed.
Payment blocked until pc wallet will be opened for trasfer the coin.
Payment blocked until pc wallet will be opened for trasfer the coin.
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.
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.
I just open the two pc wallets and togheter they are now blocked at 83,20% of download (maybe this night they where near to finish the download.
In the pool I have Ubuntu so your copy should be good (in pc, I have Fedora, but I use the Ubuntu index without problem).
However, now I will try to use the old my backup index that was done before the fork to see if it works or not
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
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
The idea of the second daemon is that it can be stopped momentarily for the purposes of snapshotting without disrupting the pool. If there's a fork, you use the snapshotted blk*.dat files to restore the blockchains on both the first and second daemons.
Using a file system that supports snapshots will be a more efficient way of storing the history of the blockchain, since it will only store the differences (additions) rather than a separate, individual copy.
As I stated above, I do an automated ZFS snapshot every 24 hours (and occasionally manually, eg installing a new version) and have never had any issues restoring from snapshotted data. The db structure is either very robust, or I'm very lucky.
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
Some of my wallets I have on 2 places, one on a laptop and one on an ext. USB-HDD, works on any windows computer. Plus I have a few USB / SD cards with all the wallet.dat files. About 3-4 backups.
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.
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)
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..
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..
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.
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..
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?
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..
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..
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
Code:
./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
Can the snapshot of blk and blkindex make even if daemon is running?
I do periodic snapshots of my whole coin drive (60+ different blockchains) and have never had any problems with the occasional restore, however, that could just be pure luck. Or maybe the db library is smart enough that it writes out new data THEN marks it as valid (so if the snapshot happens in the middle of writing a new block, the previous one will be considered the current one). Just guessing.
It is not safe to do it while the daemon is running, you could end up with a corrupted copy. [...]
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.
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
Code:
./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.
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.
Hey guys, could someone please build the latest version for mac for me?
There you go, https://github.com/iamunick/growthcoin/releases/download/1.3.1.0/growthcoin-1.3.0.1-macosx.dmg
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
delete the peers.dat file (I think you already did that)
and then try to start using the swtich -connect=188.226.240.91
and then try to start using the swtich -connect=188.226.240.91
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
Jump to: