Block generation getting "stuck" at block 401

[pennybreak]

Block generation seems to freeze at block 401. Generation will sometimes continue after stopping and restarting the daemon, but I have run into at least one case where it would never resume after stopping, starting, rebooting, etc.

I discussed this briefly with sigmike. He believes this issue may be caused by the minting thread stopping just after it starts because there's no block or coin yet.

Steps to reproduce:

1. Clone peershares repo
2. Compile daemon
3. Run daemon on two connected nodes to start blockchain
4. Wait for 401 blocks to be generated. At this point, block generation will stop.
5. Attempt to restart PoS generation by starting and stopping both daemons.

[brossi]

What happens if you let it sit for 3 days? (Serious question) Is it
maturity related, ie. is the PoW generation happening too quickly?

On Friday, March 21, 2014, pennybreak notifications@github.com wrote:

Block generation seems to freeze at block 401. Generation will sometimes
continue after stopping and restarting the daemon, but I have run into at
least one case where it would never resume after stopping, starting,
rebooting, etc.

I discussed this briefly with sigmike. He believes this issue may be
caused by the minting thread stopping just after it starts because there's
no block or coin yet.

Steps to reproduce:

1. Clone peershares repo
2. Compile daemon
3. Run daemon on two connected nodes to start blockchain
4. Wait for 401 blocks to be generated. At this point, block generation
   will stop.
5. Attempt to restart PoS generation by starting and stopping both daemons.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/71
.

[sigmike]

You can see this in debug.log when it happens:

ThreadStakeMinter started
CPUMiner started for proof-of-stake
ThreadStakeMinter exiting, 0 threads remaining

The thread should exit only when you close the program.

This problem is not maturity related. Min age is actually 36 minutes on mainnet and 5 minutes on testnet. Mainnet will be changed in #62

[brossi]

In our latest runs on a three-node testnet (using recent builds of the master branch), this still occurs and requires a node restart to start proof-of-stake minting. We have not run into situations where a node restart has not fixed the problem, but ideally, this work around would not be required.

Users can be educated about this, so it isn't a critical issue, but it is one that does provide for a less-than-great user experience (and may reduce confidence in the underlying stable product for the team that is offering the offering).

[FuzzyBearBTC]

@brossi I am running into difficulties on getting POS to start, by a node restart you mean stop the daemon on the server and restart it right? This did not seem to work for me, any advice on this would be appreciated

[brossi]

@FuzzyBearBTC - Yes, you'll want to stop both nodes after PoW ends and then restart them both.

@CoinGame - Do you have any advice based on the work you've done setting up your virtualized test environments?

[CoinGame]

Shouldn't need to restart all the nodes. Just one that mined all the shares. I think there was some vswitch times that needed to be updated as well or the clients would never start minting. Let me see if I can find them. It's been a while.

[CoinGame]

@FuzzyBearBTC @brossi I think these values need to be updated.

https://github.com/Peershares/Peershares/blob/master/src/kernel.cpp#L14

[FuzzyBearBTC]

@brossi @CoinGame many thanks for getting back to me about this issue, much appreciated 👍

1. I set the nProtocolV03SwitchTime and nProtocolV03TestSwitchTime set to a time in the future when all POW block would be mined at set it at the time of mining the genesis block.

2. Set up server nodes as opposed to local virtual machines, made sure they all connected to each other and happy, and mined the first 400 blocks to one address.

3. I waited till the nProtocolV03SwitchTime passed, sent some shares from the address holding all the shares to another address on a node, transaction showed up on the server nodes

4. stop the node which mined all the shares, waited a min or two then restarted it

5. before the restart had "ThreadStakeMinter exiting, 0 threads remaining" in the debug.log after restart have no message like that till I turn off the node again and the minting is exiting.

Was wondering if the time of stopping the node has to be before the nProtocolV03SwitchTime?

Am about to reset the nProtocolV03SwitchTime and try remining the blockchain again, Am I right in thinking that the nProtocolV03SwitchTime can be changed without a remining of a genesis block?

[CoinGame]

Fuzzy I'm going to have to look through some old notes and discussions if I can find them to verify your questions. I'll try as well to get a Peershares network running by modifying my NuDocker scripts. Give me a little time.

[FuzzyBearBTC]

@CoinGame @brossi Got POS started. Key is on point 3, the POS blocks need to have started by this epoch time, and remember to check the min age maturity for stake (STAKE_MIN_AGE)

[GeorgeKeliipio]

@FuzzyBearBTC
why the key is point 3?
can you detail the problems？
“I waited till the nProtocolV03SwitchTime passed, sent some shares from the address holding all the shares to another address on a node, transaction showed up on the server nodes”

My operation steps for example ：
pow at the time：1:00;
pow finish end at the time 3:00，then close the client;
the min age maturity for stake at the time 10:00;
nProtocolV03SwitchTime is 10:30;
open the client at the time 11:00;
than the POS started;
Is that right？

[FuzzyBearBTC]

@duoduosys Hey many thanks for your question.

The key is to open the client once all the POW blocks have been mined BEFORE ProtocolV03SwitchTime. So in your scenario you have a window of 10:00 - 10:30 to generate your first POS block.

Think of the ProtocolV03SwitchTime as the cut off date that POS blocks MUST have started by... rather than the date to allow POS blocks which is what I did at first and think you are doing the same.

In the end I increased my ProtocolV03SwitchTime to an extra day or two leaving me room to take longer generating the POW blocks, and as I am only one with code at the moment, no risk of network vulnerable etc. Hope this helps

[GeorgeKeliipio]

@FuzzyBearBTC Thank you very much, I'm confused in this place for a long time。

[FuzzyBearBTC]

@duoduosys happy to help :) took me a while to!! Feel free to ask any questions you have and I'll do my best to answer.

[GeorgeKeliipio]

@FuzzyBearBTC
I opened the client to start the POS after the min age maturity for stake ,and the POS was starting to generate some POS blocks very fast.
But after ProtocolV03SwitchTime ,the pos stopped.
I try some times anyway ,but the pos allways stopped after ProtocolV03SwitchTime.
Could you tell me why? Thank you very much,
I used the branch:master

[FuzzyBearBTC]

@duoduosys your logfile i got in an email looked all ok, there was the peerminter thread started and this did not exit which is good. The generation of POS blocks is another very good step to achieve well done :) Hmm the fact they stop at your ProtocolV03SwitchTime is a little strange.

Just to double check you have generated your own unique genesis block and changed the ports for peershares?

Keep an eye on the difficulty of POS.. as u said generates lot of blocks fast .. as difficulty low and lots of shares means the difficulty needs to readjust.

Next look out for situations where all your POW mined coins and transactions are not old enough, ie they don't meet the "min age maturity for stake" or that the coins are locked in transactions or minting and not any to generate the next block.

Are you sending any coins to wallets at the end of POW?
How many nodes mine the shares~?? just 1 or split over many nodes?
Virtual machines or actual servers??

Feel free to PM me on peercointalk.org (i'm Fuzzybear the admin on there) if you would like me to quickly look over a repo or code etc if you are not public just yet.

Fuzzybear

[GeorgeKeliipio]

@FuzzyBearBTC
I'm just too confused.. I use a lot of methods.
1 I followed with the peershares wiki, POW out 400 blocks, after the "min age maturity for stake" ,the clinet could POS the 401blocks ,the 402blocks ,the 403blocks,etc, but over time after ProtocolV03SwitchTime ，POS stoped.
2 The Second ways,POW out 400 blocks, passed the "min age maturity for stake" , the 401blocks could automatically generate, then I shut down the client ，after ProtocolV03SwitchTime to start again, but the client POS stoped，the client can not generate 402nd blocks.
I don't know why the POS stoped with the ProtocolV03SwitchTime passed?
Could you help me?
I spent too much time on the production of peershares. Why I follow with the peershares wiki,but I can't get my peershares continuing normally .
Thank you.

[sigmike]

If the protocol v03 switch time is too soon your blocks may not have had enough time to generate a stake modifier. You should set the switch time at least 6 hours after the initial block generation ends.

[GeorgeKeliipio]

@sigmike
POW start at 2015/5/31 07:24,finished at 11:51
The POS start at 2015/6/3 07:25 finished at 11:52
The protocol v03 switch time is at 6/4 10:00,
But now is 2015/6/6 16:05,the POS stoped also.
The POS always stoped with the ProtocolV03SwitchTime passed .
Why I follow with the peershares wiki,but I can't get my peershares continuing normally .
Thank you.

[sigmike]

Is there anything in the log? You may have to add extra debug information to the log to figure out why it doesn't find any valid kernel. You should probably start with CheckStakeKernelHash, CreateCoinStake or CreateNewBlock.

[FuzzyBearBTC]

@duoduosys just to say I have launched a public peershares instance https://github.com/FuzzyBearBTC/Fuzzyshares to try and show the issue you experience. I had the same issue with my Peershares implementation and managed to resolve by bringing an old wallet online that was able to mint the next block after POS switch time, but I had a master wallet that was supposed to be used for exactly this purpose and this had no effect on generating new blocks but was able to once a POS block was generated by the other wallet.

For Fuzzyshares the POSswitch time is for 10th july at midnight if i remember correctly so hopefully will be able to show and give @sigmike code and wallet to have a look at further. Just to say all POW blocks mined, POS started etc and waiting for the switch date,. 2 nodes running constantly, one local node not online atm with most shares at it, and again one other wallet with small holdings.

[FuzzyBearBTC]

@duoduosys @pennybreak @brossi @sigmike Ok I have successfully recreated @duoduosys issue with https://github.com/FuzzyBearBTC/Fuzzyshares

The last block was generated on 1436486235 epoch time GMT: Thu, 09 Jul 2015 23:57:15 GMT
nProtocolV03SwitchTime = 1436486400; // Fri, 10 Jul 2015 00:00:00 GMT

2 nodes running each with shares that should have enough coinage to stake.

I have a master wallet here I have not brought online yet with lots of shares that was how I got the network started again last time this issue occurred but will run a node in debug mode and investigate.

[ija61]

Hy to all
@FuzzyBearBTC did you find a solution for this? I have the same issue and I didn't find any info beside this thread.

Thank you.

P.S. I know is an old subject but as mentioned at this point this is the best I have.

[FuzzyBearBTC]

Hi @ija61 I found a workarround but a long time since I tested it and did the process so probably a little rusty on the fuill process.

Basically I remember creating a node that mined some early blocks. then took that node offline and let the rest of the nodes generate the other blocks up to 400. When the network gets stuck you have to bring this offline node back online and let it catch up. Once it has it will then have coins that can restart the network on POS monting. I blieve the issue possibly stems from not having the correct coindays on a free address that can be used to generate the next block. Hope this helps

[ija61]

Ok, I will test this and see what happen.

Thank you very much