1906
TestNet Discussion Archive / Re: TestNet - PODC 2.0 (Proof of Distributed Computing)
« on: November 26, 2019, 02:02:50 PM »I do support slowing down. When I upgraded all my sancs and clients were on the same testnet chain.
Today two were not running when I checked and the others were on different hashes for the same block but all sancs still appeared to be enabled on the masternode list. It should noted that previous versions could be left unattended for days.
Maybe its my VPS machines, I cannot tell, but stability has be altered since the last upgrade, whether it is due to the temporal instability in network, I cannot conclude either as there is no way I can discern the state of the network beyond the servers I control.
In addition the masternode list currently is in contrast to the non DIP3 sanc situation where the state of the network could be quickly and rather accurately discerned from the masternode list.
Well although we lost some of the fields, I do think there will be alternatives to the same info for example we have to consider these LLMQ quorums are only supposed to work within the quorum group themself who are creating the quorum from the currently allowed protoversion (another words, after a mandatory, when I increase the minimum govnance version, only those sancs can participate in the LLMQ, so theoretically, the lower sancs would fall out of the quorum and get POSE banned).
But first could we check those two as guinea pigs that have the wrong hashes? Id really like to get to the root of the problem so we can always blame it on one specific thing. Up til today, I blamed a chain fork on failure to pass the last gsc height. It was not til this version where I saw all these instantsend autolock failures.
Could you please try this:
On one, try 'exec reassesschains' and on the other, delete the instantsend.dat, then try exec reassesschains? Lets see what fixes each one?