[RE-ANN] GrowthCoin PoW/PoS - 100% per year - Version 1.3.0.1

[ice00]

Even the 2 pc wallets now are opening and they are blocked at the same block of pool (I use the same methods of bootstrap and delete even peers before open).
Wallets show 8 connections active.

[1713416904]

1713416904

[1713416904]

1713416904

[1713416904]

1713416904

[SolidStateSurvivor]

Hmm, this is odd, I see no problems when I load 1.3.0.1, should we provide you with nodes and blockchain.zip maybe?

[presstab]

Looks like allcoin froze the wallet for now.

[ice00]

It seems now that in pc the wallet it is going on but extremely slowing.
Maybe the pool still offline for this morning

[presstab]

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.

[Jamesco]

Hey guys, could someone please build the latest version for mac for me?

[ice00]

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

[unick]

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

[ice00]

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

[unick]

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

[unick]

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

[ice00]

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.

[unick]

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.

[almightyruler]

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.

[unick]

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

[ice00]

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

[unick]

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?

[ice00]

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.

[unick]

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

[ice00]

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)