BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

Hmmm, right, but they could RPC over SSL to the box and enter the pass without it going in the log, so Id rather not condone that behavior of typing it in if we can make it secure.  Let me take a look at how FTP allows the characters to be typed and see if I can make a headless test case.

So I see the miner appears to be a little more stable/faster with the last update- now we ask the miner to sign the threads cpids once and only re-sign if necessary (this keeps the lock from going off/on and prevents the crash).  Did 1110 prevent the crash for you in the miner?

Rob, appears to be better? I  opened with 6 threads and it seemed fine, switch to 8 in debug and it crashed. sleep=0.

Jaap, I just upgraded the pool server to 1110 if you want to re-associate the completely unbanked cpid and verify we dont receive an error.

As far as rewards are concerned we need a 51% supermajority on the sancs in order to start voting the correct contract for the unbanked cpid (IE by Thursday we should see some payments).

Thanks!

I tried it, and as far as I know it worked!
"Successively advertised DC-key"

Don't have much time now, sorry. And I'm on my phone, so it's difficult to give data now. But I'll get back on this tonight

Ok. Upgraded to 1110.
My observations:
On my 1-core VPS is one thread using more than 50% of CPU. Version before it was about 15%.

And Rob, my bootup unlock in WIN GUI is still not working
I don't know what can be bad here.

Ok. Upgraded to 1110.
My observations:
On my 1-core VPS is one thread using more than 50% of CPU. Version before it was about 15%.

And Rob, my bootup unlock in WIN GUI is still not working
I don't know what can be bad here.

Try setting the minersleep=500 for example, this is configurable by the user.  Ill see if I can change it back to 250ms for the next version but it doesnt seem to be a bug.

On the Win GUI, not sure what you mean by not working.

It should throw an error if you type in the wrong password.

I tried it, and as far as I know it worked!
"Successively advertised DC-key"

Don't have much time now, sorry. And I'm on my phone, so it's difficult to give data now. But I'll get back on this tonight

Good , that is half the battle, just see tonight when you exercise the new search feature:
exec search dcc cpid

See if the row is there with the unbanked cpid and the correct unbanked receive address?

Then in a couple days once we receive our first contract with the new utxo levels (of 500 per SPM), you should receive a payment.
Actually now that I think about it if you will paste that search row result, Ill check my upgraded sanc to see if the cpid is in the "future" payment (sort of like Minority Report), for some reason Im getting confused between Minority Report and the Pre-cogs (the 3 humans that are gifted) and seeing a movie one time with a dolphin with wires attached, that made lots of decisions for the group... hmmm.... 

Rob, appears to be better? I  opened with 6 threads and it seemed fine, switch to 8 in debug and it crashed. sleep=0.

How about 40 threads with sleep=1?   And btw what OS is this that keeps crashing?

How about 40 threads with sleep=1?   And btw what OS is this that keeps crashing?

Works fine until you try to change the # of threads in debug. Tried lowering to 20 and it crashed. Windows 10 Pro.

Is there anything unusual about the current contract? The mag seems to be half on 2 of my wallets. I divided my RAC with the team RAC and it doesn't seem to be right.

Try setting the minersleep=500 for example, this is configurable by the user.  Ill see if I can change it back to 250ms for the next version but it doesnt seem to be a bug.

On the Win GUI, not sure what you mean by not working.

It should throw an error if you type in the wrong password.

minersleep=1000 works for me.

And with that unlock.
At starting GUI wallet it asks me for password. I give there good password (I changed it, copy/paste, ...) and the wallet is still locked when it starts.
There is no error, only locked wallet (the lock icon is locked "wallet is encypted and currently locked", in menu is option "unlock wallet", in getinfo is "unlocked_until": 0, ... ). 
I must unlock it from menu then it works.

minersleep=1000 works for me.

And with that unlock.
At starting GUI wallet it asks me for password. I give there good password (I changed it, copy/paste, ...) and the wallet is still locked when it starts.
There is no error, only locked wallet (the lock icon is locked "wallet is encypted and currently locked", in menu is option "unlock wallet", in getinfo is "unlocked_until": 0, ... ). 
I must unlock it from menu then it works.

Are you saying it won't auto-unlock for PODC updates? Your wallet will be locked even after the prompt, it is only unlocked for the podc update.

Are you saying it won't auto-unlock for PODC updates? Your wallet will be locked even after the prompt, it is only unlocked for the podc update.

Oh. And how I know that it is unlocked? There is no "sign" about that in wallet.
After start and getmininginfo it gives me Unable to sign CPID.
Ok. Maybe I'm impatient and it'll be enough to wait, but I was thinking that it just don't work for me and unlock it manually.
But definitelly it will be good to have there some message about it that it is unlocked for PODC only.

Oh. And how I know that it is unlocked? There is no "sign" about that in wallet.
After start and getmininginfo it gives me Unable to sign CPID.
Ok. Maybe I'm impatient and it'll be enough to wait, but I was thinking that it just don't work for me and unlock it manually.
But definitelly it will be good to have there some message about it that it is unlocked for PODC only.

Yeah, it could be that we throw *one* of the unable to sign cpids in the miner when you first boot - try this, lock wallet, close wallet, open wallet - type
 the password, ensure we dont throw a password error after clicking OK on the password prompt, start the miner, if you see an error in there, do another 'setgenerate true 5' and just wait a couple minutes - ensure the error goes away and its mining.    The issue might be that we dont clear the error for about 4 mins or so into mining in the miner. 

Yes, we unlock it, sign the cpid, and lock it when the password is provided.  But we only do that if its encrypted and locked at the time cpid needs signed. 

Is there anything unusual about the current contract? The mag seems to be half on 2 of my wallets. I divided my RAC with the team RAC and it doesn't seem to be right.

Running this upcoming contract on my sanc - I ran one about 2 hours ago:
'                        public key, cpid,                          magnitude, rosettaid, team, utxoweight, taskweight, rac,   unbankedindicator, utxoamount, RAC,   InductedCredit,

'BTjJENmWrQudFHEaqEpFg7ZeCA8HK2HwLW,e94c1704c75f731f8bfde303f08408ee,109.608,1981209,     15044,50001,       100,       976594,0,                  60.00,    178404,  107042

exec search utxoweight e94
  "E94C1704C75F731F8BFDE303F08408EE (03-11-2018 18:54:10)": "832822"


Looks like it has you at a mag of 109.6, with RAC of 178404 but its only giving you 60% based on UTXO weight of 50,001 see above, that gives only 107K rac, hence the lower mag.
Looking at your timestamp on the podcupdate - it looks like you send 832,822 in at 18:54 UTC time today (thats very recent, after my sanc ran its contract)

So hopefully you will be Hit by the old contract sancs today!  I guess the lesson here is to send the podcupdate a little earlier with the 500SPM just in case, so that its "in" earlier for the newer sancs.

Sorry but I have a family birthday party Ive got to go to and also got to run a long errand so I will be gone for about 5 hours.

Running this upcoming contract on my sanc - I ran one about 2 hours ago:
'                        public key, cpid,                          magnitude, rosettaid, team, utxoweight, taskweight, rac,   unbankedindicator, utxoamount, RAC,   InductedCredit,

'BTjJENmWrQudFHEaqEpFg7ZeCA8HK2HwLW,e94c1704c75f731f8bfde303f08408ee,109.608,1981209,     15044,50001,       100,       976594,0,                  60.00,    178404,  107042

exec search utxoweight e94
  "E94C1704C75F731F8BFDE303F08408EE (03-11-2018 18:54:10)": "832822"


Looks like it has you at a mag of 109.6, with RAC of 178404 but its only giving you 60% based on UTXO weight of 50,001 see above, that gives only 107K rac, hence the lower mag.
Looking at your timestamp on the podcupdate - it looks like you send 832,822 in at 18:54 UTC time today (thats very recent, after my sanc ran its contract)

So hopefully you will be Hit by the old contract sancs today!  I guess the lesson here is to send the podcupdate a little earlier with the 500SPM just in case, so that its "in" earlier for the newer sancs.

Sorry but I have a family birthday party Ive got to go to and also got to run a long errand so I will be gone for about 5 hours.

Thanks for looking into it, hope you have a good time.

Yeah, it could be that we throw *one* of the unable to sign cpids in the miner when you first boot - try this, lock wallet, close wallet, open wallet - type
 the password, ensure we dont throw a password error after clicking OK on the password prompt, start the miner, if you see an error in there, do another 'setgenerate true 5' and just wait a couple minutes - ensure the error goes away and its mining.    The issue might be that we dont clear the error for about 4 mins or so into mining in the miner. 

Yes, we unlock it, sign the cpid, and lock it when the password is provided.  But we only do that if its encrypted and locked at the time cpid needs signed.

So, it is OK. It works and I was too impatient. But I still think that visual "alert" for this need improvement Maybe it will be enough to change the onhover text on lock to "Wallet is encypted and unlocked for PODC only". Thanks Mike and Rob for clarification.