** DETERMINISTIC SANCS / GIN / PROD **


I promised to mention the status of Prod/dip3 and Deterministic sancs upgrade.

So our prod chain has voted in dip3 successfully, and we will soon be able to continue upgrading to deterministic sancs in prod.

But I would like to make one small change to the schedule.

Since it is so late into July, and our superblock is near, lets postpone the deterministic sancs upgrade until August (after our July superblock pays out).

I will modify the schedule now.

https://wiki.biblepay.org/Evolution_Upgrade

Good point.  He could possibly investigate other explorer branches - but so far I see Dash-Green is also running iquidis.  MIP maybe you can find out what explorer Dash uses when you have a free minute.

This is more related to some prior projects - not iquidis, but its worth a try, could you try this in the config:
rpcthreads=500
litemode=1

And resync? 
I was under the impression with Evo we were communicating much faster with Iquidis (I remember you said there is a big difference), but apparently iquidis gets hung occasionally.

So also could you clarify if the node itself is stuck 200 blocks behind, or is it iquidis that ceases to sync?  (If its not the node, there is no need to resync the entire chain, if its iquidis we would just resync the iquidis database.  But the rpc settings might help if its too dumb to recover).  Maybe the daemon is dying, maybe research how to persistenly keep the daemon running also.

Btw, I sent you a PM and 2 emails but have not received a reply.

Let's try to find the root cause.  Do you happen to have the log of one of the machines before it went out of sync?

B) Is this machine running with litemode=1? 

We need to see if the machine is having trouble getting gov data.
Do you have tons of banned peers in the peers list?

I just ran my global sanc report and 100% of the nodes are in agreement with Chainz and my local node and the pool:

getblockhash 132922

03fe0f4fbd2ab5848404eb4dfddc543a1f759711201d4841af0169e2d4467e31

In this case it looks like explorer.biblepay.org is wrong - please resync the chain with the -erasechain=1.
Ive seen this happen after a reindex (reindex is not good for Biblepay, we will need to address this right now for the next version.  Im adding to my punchlist now).

If anyone ever goes out of sync, please start with -erasechain=1 and dont do the reindex suggestion that other communities use.  (It does not clean up governance at all and cant handle compact blocks or non fin tx or prayers or SAN data leaving your node in a corrupt state).

EDIT:  explorer.biblepay.org is not forked - its stuck on a block 500 blocks back (look at its hash)

I wonder if we should retire this explorer - if its going to be unreliable.  Togo, can you reset it?

We get a little bit of spam per block change in this version, just let it go for tonight and see if you fail to get an ABN for more than 5 mins.

In the next version, Ill make it do an extra test each time it gets an ABN and keep it out of the log, that should help keep the log clean.

What is the timestamp range of stale blocks in the log, did it continue?  I believe this is normal behavior.

I think you are fixed;  it takes 3-5 mins for all errors to clear.

But the root of the issue was you couldn't get a valid ABN, now you have one.

Also, now if you drill into the leaderboard, you can see the health columns went to 100% now.

No, I mean to see if the problem miner now has a valid ABN?

I made a change to the pool to attempt to reveal the problem, did it just resolve (try to 'setgenerate true N') on one of the nodes?

I dont see a miner by the name of Nipar, please share miner name.

Could you please paste or PM me the main part of the log that is complaining about the block?

Ok, I just deployed 1.4.4.3b (Windows only).  It has that fix in it that supposedly clears the cached abn.

Could you please try it now?

Oh ok, interesting that you rebooted the client.  I did mean client in this case.  What OS is this, btw? 

Ok, I think I have enough info then, I believe this is the same problem MIP had yesterday in testnet; we have a situation where the invalid ABN gets cached, and in the next version this is fixed (where the cache gets cleared when the log says "no block to mine").

So I make the assumption that if you reboot the node, and restart the miner it will get a valid ABN from the pool; can you please try that?

Yeah, this is very interesting, because I was able to boot up my dev miner in funded mode and get an abn, while yours didnt get it so thats very strange.

Have you changed the name of the miner from "Vader" to "Vader 2" recently, or was it always "Vader 2"?

(Just want to rule out spaces in the name).

I see Vader 2 has contacted the pool 289 times in the last 15 mins, so I can see it cant get what it wants but it is trying; has Vader 2 ever worked properly?

(As a funded miner)?

Right, I should have asked another way;  Correct, that is one nice thing we can tell anon-sensitive users who don't want to deal with the headless password- they can mine as funded miners.

Anyway, let me check something on vader -can you please see if 'exec getabnweight 125000 1' actually returns > 125000 abn weight?  Because if it has enough funds it could be trying to mine with the ABN.

Ok, Please leave it in that state, let me see if my desktop can reproduce.

It does not have a locked wallet correct?

Im working hard to eliminate that asap.  I cant eliminate that yet as it would give too much of the pool away to the top 3 miners.

So aside from the fund switch issue, did vader start working by itself?    Cause Im not receiving any complaints about the fail to get abn.  I know it happens occasionally but it should not be much cpu time in total.  I believe it happens between block changes mostly.