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

[Rob Andrews]

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.

[T-Mike]

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.

[orbis]

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.

[T-Mike]

Rob, is there a way to see which contract currently has the most votes? Thanks.

[MIP]

I think we have a bug- PODC stake has used my 1550001 BBP of my sanc for staking, even if it's supposed to be locked

See:
http://explorer.biblepay.org:3001/tx/0321cce7ad6a91a707c4512e32c1bd13d31754233e7cd0403b7dee7face0c4d8

Now my sanc is "missing" :-(

Edit: I think it's because I cloned the wallet into another PC. Anyway, the lock enforcement should work at the blockchain level I think.

[Rob Andrews]

I think we have a bug- PODC stake has used my 1550001 BBP of my sanc for staking, even if it's supposed to be locked

See:
http://explorer.biblepay.org:3001/tx/0321cce7ad6a91a707c4512e32c1bd13d31754233e7cd0403b7dee7face0c4d8

Now my sanc is "missing" :-(

Edit: I think it's because I cloned the wallet into another PC. Anyway, the lock enforcement should work at the blockchain level I think.

No, its not a PODC bug, we iterate through your UTXOs and honor the locks.  I would check to ensure you have re-locked your hot funds during each start.

Do you have a masternode.conf file set up with the Sanc's hot txid in it?

[Rob Andrews]

Rob, is there a way to see which contract currently has the most votes? Thanks.

The only way to do it right now is to go to the sanc, and type 'gobject list all triggers', copy that to notepad and find the one with the highest votes.
Then you can 'gobject get gobjectid' to see the info.

I decided since we were getting so many questions about the upcoming contract, Im going to write a feature that allows the Pool to pull in the current "upcoming" contract into a pool page for viewing by everyone.  Hopefully it will answers the lions share of the questions, like UTXO amounts and am I in it, although Im doing this in a way where its going to pull my First sanctuaries (sanc1) into the pool 4 times per day, so I cant guarantee "my" sanc will be "the" voted contract!  But at least it should be 95% accurate most days, since Im going to have the same data as everyone else.  Im thinking of storing this info in history also, so we can make a chart of Magnitude by CPID, and maybe allow Capulo to drill into Yesterdays contract to check his yesterdays rac, etc. 

[MIP]

No, its not a PODC bug, we iterate through your UTXOs and honor the locks.  I would check to ensure you have re-locked your hot funds during each start.

Do you have a masternode.conf file set up with the Sanc's hot txid in it?

In one PC I do, but not in the other wallet with the sanc. controller address. So it's possible that for this wallet that UTXO was not locked.

[Rob Andrews]

In one PC I do, but not in the other wallet with the sanc. controller address. So it's possible that for this wallet that UTXO was not locked.

In testnet, I noticed that when I ran a hot sanc, I had to manually lock the row every day, which is a big nuisance, but in Prod, while using my masternode.conf file, the bootup sequence of the wallet locks every txid in the list, so even with all my PODC updates, I never have spent my locked funds in prod.

I also attempted to make sure the wallet does not spend anything equaliing SANCTUARY_COLLATERAL, but when you said earlier it spent one, Im thinking maybe that amount is Off in the wallet and only half of the feature is working. LOL.  So Ill check on #2 later today in the mean time try to do the masternode.conf then reboot and look in coin control and if its locked you should be OK.

[Rob Andrews]

In one PC I do, but not in the other wallet with the sanc. controller address. So it's possible that for this wallet that UTXO was not locked.

Ok yes, you discovered a certain unintended bug.     Fixed in the next version - now the wallet will not spend sanctuary funds in PODC updates or Associations.

[jaapgvk]

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

Code Select Expand


21:21:49

exec search dcc 8791a036b545f35e9ebd9333922738ac


21:21:49

{
  "DataList": "DCC",
  "8791A036B545F35E9EBD9333922738AC (03-11-2018 16:50:26)": "8791a036b545f35e9ebd9333922738ac;BNfb6uMyeAHDwZs538gzxS2k2iqbz8NWQj;BNfb6uMyeAHDwZs538gzxS2k2iqbz8NWQj;1986929;;1"
}


Looks good 

Don't know that dolphin movie btw, haha! If you ever remember the title, I'd like to know it 

[Rob Andrews]

Code Select Expand


21:21:49

exec search dcc 8791a036b545f35e9ebd9333922738ac


21:21:49

{
  "DataList": "DCC",
  "8791A036B545F35E9EBD9333922738AC (03-11-2018 16:50:26)": "8791a036b545f35e9ebd9333922738ac;BNfb6uMyeAHDwZs538gzxS2k2iqbz8NWQj;BNfb6uMyeAHDwZs538gzxS2k2iqbz8NWQj;1986929;;1"
}


Looks good 

Don't know that dolphin movie btw, haha! If you ever remember the title, I'd like to know it 

Great, so now since we have the pool contract report, (Reports | Superblock View) we can just go into the pool and search for 8791.  So to find out if you have any magnitude, take a look RAC and Modified RAC.  RAC = 54, Modified RAC = 54.  This shows a mag of .044.  If the CPID was penalized for taskweight or utxoweight, the modified RAC would have been lower or 0, so everything appears to be working, all we have to do is wait for the supermajority to run the latest sanc code and the payments should start.

I havent encountered any new showstoppers so I think we can announce the mandatory tomorrow and possibly re-enable the exchanges.

Im adding one more rule tonight for the potential of stake-per-rac processing.

[Rob Andrews]

Biblepay - 1.1.1.1b
Mandatory Upgrade before block 35110


- Headless PODC Password support:
  ./biblepay-cli -headlesspodcpassword  <enter>     ,  then Enter password on next line.  Step 2 (optional): exec podcpasswordlength
- Added icon in QT for PODC Association, and icon for PODC Update
- Prevent wallet from spending Sanctuary collateral during PODC Update
- Add support for Required Stake-Per-RAC pending poll outcome


** Windows is compiling **

This is a prerelease, checked in now, available for linux.  It turns out this will need to be mandatory for the whole network due to that new 'potential' stake-per-rac feature pending the poll outcome. 

In the mean time if anyone wants to test the headless password prompt, go for it.

[T-Mike]

Biblepay - 1.1.1.1b
Mandatory Upgrade before block 35110


- Headless PODC Password support:
  ./biblepay-cli -headlesspodcpassword  <enter>     ,  then Enter password on next line.  Step 2 (optional): exec podcpasswordlength
- Added icon in QT for PODC Association, and icon for PODC Update
- Prevent wallet from spending Sanctuary collateral during PODC Update
- Add support for Required Stake-Per-RAC pending poll outcome


** Windows is compiling **

This is a prerelease, checked in now, available for linux.  It turns out this will need to be mandatory for the whole network due to that new 'potential' stake-per-rac feature pending the poll outcome. 

In the mean time if anyone wants to test the headless password prompt, go for it.

That's great! What is the exec podcpasswordlength for?

[Rob Andrews]

That's great! What is the exec podcpasswordlength for?

You can use it from headless to check that the password was memorized.  Its just a sanity check.

Windows has been deployed if anyone wants to test it.

I think we are OK to release this afternoon, from what I can tell.

This latest version handles either poll outcome.

Id like to inform exchanges to upgrade late tonight, so please if anyone has any concerns please post, and please test anything remaining.