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

Ok, but how do you join your rosetta acc to wallet in Coinomi (if it will be)? Is it enough to change your "web page" in rosettas acc? I see that there is my controller wallet written.
And I really hope, that no one will exploit it. It would be big disadvantage for "normal" users.

So far I dont know of a way - because BOINC stamps the processor type in the distributed network AFTER the machine asks for a certain architecture of work, so we will see if it holds up.  Its going to be pretty apparent because IM going to write reports showing magnitude by CPID, so we will know if any unbanked CPID ever gets past say a 100 magnitude etc.

Anyway, that is most certainly a good question on coinomi.  Right now you would have to be able to type 'éxec associate' in order to associate that thing at home on your laptop!  So I dont have an answer for you.  But what we can do is, if we move into the integration phase with coinomi, I can ask them if we can have a custom feature added!  Maybe we have to pay a couple grand for it.

I have another idea though.  I can make the pool offer free associations for boinc users.  So if coinomi cant do it, we can do it from the pool.  The pool can pass the info into the rpc command and broadcast it and destroy the credentials, so that works!  Problem solved either way...

The GUI of the pool can just display the result of the burn, and the pool can pay the 1bbp fee.

Actually I think to accomodate the unbanked, Ill work on that before March 15th.

I have another idea though.  I can make the pool offer free associations for boinc users.  So if coinomi cant do it, we can do it from the pool.  The pool can pass the info into the rpc command and broadcast it and destroy the credentials, so that works!  Problem solved either way...

The GUI of the pool can just display the result of the burn, and the pool can pay the 1bbp fee.

Actually I think to accomodate the unbanked, Ill work on that before March 15th.

That would be great.
Many thing was done (thanks Rob) and it seems that everything is going well.
What else remains to do before March 15?

bottomline
Rob thanks for correcting the wallet window size. Now it's great.
And is somewhere a list of all exec commands? (someone asks about it here before)

That would be great.
Many thing was done (thanks Rob) and it seems that everything is going well.
What else remains to do before March 15?

bottomline
Rob thanks for correcting the wallet window size. Now it's great.
And is somewhere a list of all exec commands? (someone asks about it here before)

There are a few things left to do, let me see if I can do a diff on what we have created and get back to you.
Today Im going to check the chain integrity - we need to ensure everything we are changing in prod will not affect syncing from zero, or reorganizing.

Regarding the exec commands, most of these are not really intended for the user to run, so I deliberately made them exec commands.  In the long term I envision commands that the user needs, such as exec getboincinfo, should be made into real RPC commands with help.  But nevertheless let me look at which exec commands are relevant.  Out of 20, I think we really should only document a few of these (as most are for diagnostic purposes).

Here is a list of the PODC related exec commands and definitions.

These will need to be added to the wiki.  I will be adding these to the wiki over the next 7 days.

My plan on the whitepaper is this:  We go live sometime in March with PODC, primarily to unplug the botnet and ensure our valuable emissions are going to researchers.  While that process is transitioning, I finish the whitepaper, send it to Luke who helps mark it up (this makes it look more professional), then I will send it in for peer review (this process could take a Year), so I look at this as something we do in the backgorund while we are live on PODC.

Remember, the people at the Journal know very little about blockchain programming - they are going to be asking Me questions about the interfaces, so I hope that clears up any confusion on why its being done in this order.

Exec RPC Commands related to PODC:

exec podcdifficulty
- PODC Difficulty is derived by how many concurrent researchers participated in the Last superblock * Their Respective Magnitudes.  This gives an idea how hard it will be to earn money on the PODC side in the next superblock.

exec podcupdate
- This forces a podc update.  Useful if you left your machine off by accident for a long period of time and your task weight or utxo weight dropped to zero.

exec associate
- This associates a CPID with a Biblepay public key.

exec leaderboard
- This shows the respective Research CPID participants and corresponding magnitudes as of the last superblock descending by magnitude.

exec getboincinfo
- This shows most of the important boinc/rosetta metrics, allowing a researcher to diagnose integration issues, and allows one to verify their current magnitude and magnitude trend.

exec unbanked
- This report shows a list of CPIDs who are unbanked.  Unbanked means CPIDs with 100% of the RAC originating from ARM devices, and none of the RAC originating from Non-Arm devices.  **Note this report is currently showing a list of Rosetta IDs not cpids, I will fix this report today to show one CPID per row**

exec sins
- This is a report on 40 sins that may send you to Hell if you are unrepentant.


I will go into more detail as I merge these into the wiki.

Mini update on the Zotac vs the Ryzen:  Dont give up on the Zotac, its really starting to shine now, believe it or not.
Zotac RAC 460, Ryzen RAC 710!  That means zotac is doing 65% of the RAC of a ryzen, yet it costed less than half and its wattage is 1/10th that of the ryzen.  It may actually prove to be "the winner" in the end...   

Mini update on the Zotac vs the Ryzen:  Dont give up on the Zotac, its really starting to shine now, believe it or not.
Zotac RAC 460, Ryzen RAC 710!  That means zotac is doing 65% of the RAC of a ryzen, yet it costed less than half and its wattage is 1/10th that of the ryzen.  It may actually prove to be "the winner" in the end...

Let's see if my estimate is accurate after 4 weeks:
My computer with an ATOM processor gets about half the CPU mark as the CPU you have in your computer and has the same number or cores. Your Ryzen 1700x estimation comes from comparing it to 2 different CPUs with known credits/day and by using the scores from cpubenchmark.net. The predictions are for full CPU usage without any interference.

Zotac: 1,800RAC max
1700x: 17,305RAC max

Let's see if my estimate is accurate after 4 weeks:
My computer with an ATOM processor gets about half the CPU mark as the CPU you have in your computer and has the same number or cores. Your Ryzen 1700x estimation comes from comparing it to 2 different CPUs with known credits/day by using the scores from cpubenchmark.net. The predictions are for full CPU usage without any interference.

Zotac: 1,800RAC max
1700x: 17,305RAC max

Ok cool, we will see.


Who wants to test exec associate?  To refresh everyones memory it used to allow you to know if INVALID_CREDENTIALS works, Or ALREADY_IN_CHAIN, or the ability to re-associate with a new wallet. Could someone please thoroughly test those at least those 3 things?

Btw, to know if re-association works:  run exec datalist dcc first, copy the CPIDs row information to notepad.  Note how a certain BBP public address is associated with the CPID at that time.  Then reassociate the CPID with a new public biblepay key (by replacing wallet.dat with a new wallet).  Then wait 6 confirms, then type exec datalist dcc again.  Verify that Only One Row exists for the cpid (as last most recent row wins in BBP) also verify the new Address is now associated with the CPID.  Then if you want maybe put it back to your old wallet if its a good cpid.

Youll need 10 BBP in the new wallet to perform reassociations.

Unbanked report is now fixed for next version, we are getting there!

Any concerns by anyone, or anything anyone wants to ask, or double check, or any reservations to going live on March 20th?

Im thinking maybe we test another 7 days and ensure "quietness abounds" then we give CCEX and SouthXChange a 10 day upgrade notice.

Mini update on the Zotac vs the Ryzen:  Dont give up on the Zotac, its really starting to shine now, believe it or not.
Zotac RAC 460, Ryzen RAC 710!  That means zotac is doing 65% of the RAC of a ryzen, yet it costed less than half and its wattage is 1/10th that of the ryzen.  It may actually prove to be "the winner" in the end...

Rob i think that something is wrong with your Ryzen.
Look at e.g. Togos or Klondikes comupters. They have more Ryzens 1700 and theirs Ryzens RAC is a lot higher than yours. And it is not caused by time... because they starts to "compute" with them only few days ago. And it looks that you have more powerful CPU (1700x).

Rob i think that something is wrong with your Ryzen.
Look at e.g. Togos or Klondikes comupters. They have more Ryzens 1700 and theirs Ryzens RAC is a lot higher than yours. And it is not caused by time... because they starts to "compute" with them only few days ago. And it looks that you have more powerful CPU (1700x).

You know that makes sense to me, because this thing is a monster, let me check it out and see if its going to sleep... I might have accidentally left it in auto-sleep mode.  Another possibility is its running windows 7, and I have a warning on the screen:  unsupported operating system (LOL).

I've attached an Excel file to show percentage increase of RAC over the weeks.

Ok cool, we will see.


Who wants to test exec associate?  To refresh everyones memory it used to allow you to know if INVALID_CREDENTIALS works, Or ALREADY_IN_CHAIN, or the ability to re-associate with a new wallet. Could someone please thoroughly test those at least those 3 things?

Btw, to know if re-association works:  run exec datalist dcc first, copy the CPIDs row information to notepad.  Note how a certain BBP public address is associated with the CPID at that time.  Then reassociate the CPID with a new public biblepay key (by replacing wallet.dat with a new wallet).  Then wait 6 confirms, then type exec datalist dcc again.  Verify that Only One Row exists for the cpid (as last most recent row wins in BBP) also verify the new Address is now associated with the CPID.  Then if you want maybe put it back to your old wallet if its a good cpid.

Youll need 10 BBP in the new wallet to perform reassociations.

Ok. I've tested it.
First associate without force and it works: ALREADY ON CHAIN
Tan with force (at block 11320): Successfully advertised DC-Key. ....
after 6 blocks changed my address from yfvTaGZakXWsLqyTCSZRG3kqabY6WYhFym to yZYt9boPur9vMLC5CPrWuiwXQ2XzzpXMVJ
with exec podcupdate had UTXO and taskweight at 100 in a block
magnitude at 0.
checked with exec datalist dcc and looks OK.
BTW you can check your wallet easier in rosetass profile URL (it changed too)
Then jumped back to my old testnet wallet without problem. Thanks God it works without problem

On the Topic of Ryzen 7 1700 (3.0GHz),

apparently they can go up to 4.1GHz or so and I think thats what the Top Ryzen 7 1700 machines on Rosetta are using to get 10k RAC
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=3194869
https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=3291011

I have both of my ryzens now overclocked to 3.8GHz

and for the i7 2600k I bumped it from 3.4GHz to 3.8GHz yesterday.

I have no experience overclocking so this has been interesting

I've attached an Excel file to show percentage increase of RAC over the weeks.

This is a relatively impressive spreadsheet, in that I see that it uses the correct exponent function (2.71) that BOINC uses and the decay formula appears to be correct, but I see a few bugs in the sheet that causes it to lag over time:

- This does not take into consideration the compounding effect of RAC.  RAC is compounded at least once per day (roughly) when a host solves a WU.  For example, lets say machine A had zero rac, and worked for 24 hours to solve a 100 RAC workunit, once per day.  That means it would check in One Day after epoch, 86400 in since inception with 100 credits, and while those 100 are granted, its first decay point would be ONE day, its RAC IN would be the age of its PRIOR RAC (of 0).  On Day 2, its prior rac of 100 would be 2 days old and its new 100 credit would be 1 day old.  With a grand total of 189 rac on day 2.


So you must add a running total to this to show the prior days RAC total, and the new total so that they always are able to be decayed separately per the formula (Not 0 for one and the grand total for the IN).

- If the machine is crunching 100 new Credits per day, then the grand total in 4 weeks must be a RAC of 903 (not 100).  100 Credits per day means 100+100+100... = 500 RAC on week 1...  Not 50 rac on week 1.

So I think if you add a running total for Prior days End and New days begin it will match boinc. 
A 100 RAC input should yield a 920~ or so RAC at the end of the 31 day period...

Great job!

Ok. I've tested it.
First associate without force and it works: ALREADY ON CHAIN
Tan with force (at block 11320): Successfully advertised DC-Key. ....
after 6 blocks changed my address from yfvTaGZakXWsLqyTCSZRG3kqabY6WYhFym to yZYt9boPur9vMLC5CPrWuiwXQ2XzzpXMVJ
with exec podcupdate had UTXO and taskweight at 100 in a block
magnitude at 0.
checked with exec datalist dcc and looks OK.
BTW you can check your wallet easier in rosetass profile URL (it changed too)
Then jumped back to my old testnet wallet without problem. Thanks God it works without problem

Wow this is awesome, Thanks!!!!