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

[Rob Andrews]

I had an issue with my wallet, it kept crashing, tried all the normal recovery steps and nothing worked.  Since it was a pure test wallet, I ended up downloading a fresh copy of the biblepay client and cleaned out all files in the biblepaycore window (including my wallet).  After installing, mining a block and waiting for it to mature, I tried exec associate email pass and it responded "INVALID_CREDENTIALS", adding force to the end of the command did not change it.

Invalid credentials means the credentials are not correct.  Try logging into the web portal first, then retry association. 
Btw, if you keep a copy of your wallet.dat, you will not need to reassociate.

EDIT: Force is only required if you receive the error: ALREADY IN CHAIN.

[orbis]

Yes, could you please be our guinea pig?  Lets just leave it hidden til you reach 0 reward and let us know when that happens (how many hours it took) then unhide it and watch it go back up.

OK.
So we can starts to count it from now
If it is only in testnet it is no problem

[Rob Andrews]

So I wasn't sure where"retry association" was, so I quit Team Biblepay, then rejoined.  But the error continued.  I was able to restore a previous wallet.dat file and it is correctly associated, but am unclear why the process would have failed on a new wallet (which is an unlikely situation to be in but...)

You won't have to ever quit Team Biblepay, it won't change any association business logic.
"The error continued", you mean Invalid Credentials?  - Answered Earlier.
If you change wallets, you should receive an "ALREADY IN CHAIN" message, once you enter the correct credentials.

[Rob Andrews]

One suggestion for the wallet to improve readability.  Could there be different mining categories?  So a Bible Icon for PoBH, a Church Icon for Sanctuaries and perhaps the atom (?) icon for PoDC?  And perhaps allow for these each to be shown  collectively under mining but also broken down by subcategory?

Icon's would definitely be nice.  That would be a nice cosmetic addition to the wallet.

Maybe you can reach out to Togo and see what kind of help he needs in recruiting a co-developer so we can have a dedicated testnet branch with features like that merged in for testing?

[rastiks]

Rastiks I see your machine right above your other ARM has 1.9GB ram and a BLANK for the processor.  What machine is that?

That was actually one of my ARM single-board computers. Not an Android mobile or tablet. But since it is running Linux, although I was able to connect it to rosetta@home, I wasn't able to solve any task with it, since Rosetta does not support ARM on Linux (other boinc projects do). And I tried very hard :-)

In general, you cannot assume that any ARM processor is a mobile or tablet: there are very high-performance multicore ARM servers (e.g. https://cavium.com/product-thunderx-arm-processors.html), there is even a 99$ ARM notebook (https://www.pine64.org/?page_id=3707).

BUT, the fact that you cannot leverage Linux-based ARM machine in Rosetta protects us a bit.

[Rob Andrews]

Update on the next version - 1094c:

So I did a lot of expirimentation with the threading today, and have come to the conlcusion Jaap had a point, the wallet was using too much power even with the new settings in distributedcomputing mode.

So what I have done is in Distributed Computing mode the miner behaves slightly differently (in the next release).  It respects the CPU's thread priority meaning that it can run slower, and we now allow you to tweak the setting.

There will be a new setting called minersleep (the default is 0 for Prod and 250ms for Testnet).  If you set a numeric value you override it.
Now Im seeing about 10% proc usage by default, and when I raise the value, it does allow the machine to sleep more (down to more like 4% or so).

1094c is now out there for linux if anyone wants to expiriment.  This is a pretty minor change, so if you want to wait for the next release its no big deal.

Im compiling Windows now so we will have this to play with later tonight.

PS I did get the unbanked report working for the sanctuary validation system in unit test mode, but its not going to be ready til sometime tomorrow.

[Rob Andrews]

That was actually one of my ARM single-board computers. Not an Android mobile or tablet. But since it is running Linux, although I was able to connect it to rosetta@home, I wasn't able to solve any task with it, since Rosetta does not support ARM on Linux (other boinc projects do). And I tried very hard :-)

In general, you cannot assume that any ARM processor is a mobile or tablet: there are very high-performance multicore ARM servers (e.g. https://cavium.com/product-thunderx-arm-processors.html), there is even a 99$ ARM notebook (https://www.pine64.org/?page_id=3707).

BUT, the fact that you cannot leverage Linux-based ARM machine in Rosetta protects us a bit.

Ok great, thanks!  Yeah, I added that ARM (with blank proc) to the list in a way that it wouldnt disqualify you as an unbanked individual.
Regarding someone with only arms, and running in high power mode with the benefit of no controller wallet, I think all they really gain is not having a controller wallet anyway, so big deal, as long as we get our 98% integrity rating for the rest of the farm, Im ok with that .  But if you guys see any heinous advantage, please, raise it as an issue and we can then put a Magnitude limit on the ünbanked CPIDs.  Those ARM tablets still only receive the same compensation as the banked cpids, (except they arent staking any capital so they get a free 100% utxo weight).

[Rob Andrews]

Yes, I tried exec asssociate with and without force multiple times and it continued "INVALID_CREDENTIALS", both when manually typing and cut and paste from the original file I used as well as trying the form on the main wallet as well as debug.  I didn't understand what you meant by "retry association" on Rosetta@home site, didn't see a link that was similar to that which is why I tried Quit and Rejoin Team Biblepay.

The only solution was restoring an old wallet backup from my testnet backups I maintain, works fine.  So not sure if there is a bug out there or if doing what you intended with retry association would have been sufficient but thought you should know.

Oh your right, I just reproduced that with my cpid, something changed.

Let me debug that problem next...

[Rob Andrews]

Yes, I tried exec asssociate with and without force multiple times and it continued "INVALID_CREDENTIALS", both when manually typing and cut and paste from the original file I used as well as trying the form on the main wallet as well as debug.  I didn't understand what you meant by "retry association" on Rosetta@home site, didn't see a link that was similar to that which is why I tried Quit and Rejoin Team Biblepay.

The only solution was restoring an old wallet backup from my testnet backups I maintain, works fine.  So not sure if there is a bug out there or if doing what you intended with retry association would have been sufficient but thought you should know.

No wonder I was so confused!  I made the assumption the code was still working the way it was when I tested it last week.
So anyway when I added the podcupdate feature, it broke a couple of the return codes (or circumstances) inside the 'éxec  associate' feature.  So those are now fixed, and now people will see "ALREADY_IN_CHAIN" or "INVALID_CREDENTIALS" during the proper circumstances, in the next version.

Im checking in 1.0.9.4d now for linux if anyone wants to test that tonight.   Starting windows build over.

Lets check this out tomorrow when we have a chance to ensure reassociation works now.

Thanks for pointing out this bug!

[orbis]

Icon's would definitely be nice.  That would be a nice cosmetic addition to the wallet.

Maybe you can reach out to Togo and see what kind of help he needs in recruiting a co-developer so we can have a dedicated testnet branch with features like that merged in for testing?

When we are talking about visual. I don't know if it is only my problem, but I'm not able to reduce wallet window size below some px (It is approx 90% of my screen height) And in testnet I'm unable to reduce it below maybe 110% of screen size, so I'm unable to see status bar and I must maximize my window to see everything. I have Win10. It is only my problem or it is common? Is possible to solve it?

[T-Mike]

When we are talking about visual. I don't know if it is only my problem, but I'm not able to reduce wallet window size below some px (It is approx 90% of my screen height) And in testnet I'm unable to reduce it below maybe 110% of screen size, so I'm unable to see status bar and I must maximize my window to see everything. I have Win10. It is only my problem or it is common? Is possible to solve it?

What's your resolution set to? If it's below 1024x768 you might not see the whole window.

[T-Mike]

If Taskweight and UXTOweight are zero, should my magnitude be zero? I forgot to turn PoBH on.

Code Select Expand


"version": 1000904,
  "protocolversion": 70715,
  "walletversion": 61000,
  "wallet_fullversion": "1.0.9.4",
  "balance": 14328660.49245012,
  "privatesend_balance": 0.00000000,
  "retirement_balance": 0,
  "blocks": 6700,
  "timeoffset": 0,
  "connections": 12,
  "proxy": "",
  "difficulty": 0.2833186345714879,
  "testnet": true,
  "keypoololdest": 1518115544,
  "keypoolsize": 1001,
  "paytxfee": 0.00000000,
  "relayfee": 0.00010000,
  "errors": ""

"Command": "getboincinfo",
  "CPID": "4fd1bf6c6900d92b226e16c6a6935661",
  "Address": "yWQfYmBCAQrcn9RkjM9DJwWGfgjHdvpZwn",
  "CPIDS": "4fd1bf6c6900d92b226e16c6a6935661;",
  "CPID-Age (hours)": 422068,
  "NextSuperblockHeight": 6732,
  "NextSuperblockBudget": 1359680,
  "4fd1bf6c6900d92b226e16c6a6935661_RAC": 820.6,
  "4fd1bf6c6900d92b226e16c6a6935661_TEAM": 15044,
  "4fd1bf6c6900d92b226e16c6a6935661_TaskWeight": 0,
  "4fd1bf6c6900d92b226e16c6a6935661_UTXOWeight": 0,
  "Total_RAC": 820.6,
  "Total Payments (One Day)": 0,
  "Total Payments (One Week)": 546564,
  "Total Budget (One Day)": 13700330,
  "Total Budget (One Week)": 67535384,
  "Superblock Count (One Week)": 63,
  "Superblock Hit Count (One Week)": 49,
  "Superblock List": "6633,6534,6435,6336,6237,6138,6039,5940,5841,5742,5643,5544,5445,5346,5247,4653,4554,4257,4059,3861,3762,3267,3069,2970,2871,2772,2673,2574,2475,2376,2277,2178,2079,1980,1881,1782,1683,1584,1485,1386,1287,1188,1089,990,891,792,693,594,495",
  "Last Superblock Height": 6633,
  "Last Superblock Budget": 1359680,
  "Last Superblock Payment": 0,
  "Magnitude": 8.09300203283067


[jaapgvk]

Update on the next version - 1094c:

So I did a lot of expirimentation with the threading today, and have come to the conlcusion Jaap had a point, the wallet was using too much power even with the new settings in distributedcomputing mode.

So what I have done is in Distributed Computing mode the miner behaves slightly differently (in the next release).  It respects the CPU's thread priority meaning that it can run slower, and we now allow you to tweak the setting.

There will be a new setting called minersleep (the default is 0 for Prod and 250ms for Testnet).  If you set a numeric value you override it.
Now Im seeing about 10% proc usage by default, and when I raise the value, it does allow the machine to sleep more (down to more like 4% or so).

1094c is now out there for linux if anyone wants to expiriment.  This is a pretty minor change, so if you want to wait for the next release its no big deal.

Im compiling Windows now so we will have this to play with later tonight.

PS I did get the unbanked report working for the sanctuary validation system in unit test mode, but its not going to be ready til sometime tomorrow.

Great! I must say beforehand: Both AMD rigs I was telling you about were using the windows wallet. Looking back, could it be possible that the windows wallet (pre 1094c) wasn't using the 250ms setting yet?

Because just now I tested the new wallet on my linux rig, and out of the box (250ms) the cpu usage is already much lower than before. When I set it to 0ms it's back up to it's old values again.

I now set it to 500ms, and I'm able to get BOINC running along nicely while also mining (it's a véry slow AMD E-450 laptop) . I think it's great to have a 'one-go-solution' to tweaking the settings so that BOINC and one-thread-mining can go hand in hand, because I can imagine that a lot of people will be using only one computer to generate BBP.

[orbis]

What's your resolution set to? If it's below 1024x768 you might not see the whole window.

My resolution is FHD 1920*1080.

[Rob Andrews]

If Taskweight and UXTOweight are zero, should my magnitude be zero? I forgot to turn PoBH on.

Code Select Expand


"version": 1000904,
  "protocolversion": 70715,
  "walletversion": 61000,
  "wallet_fullversion": "1.0.9.4",
  "balance": 14328660.49245012,
  "privatesend_balance": 0.00000000,
  "retirement_balance": 0,
  "blocks": 6700,
  "timeoffset": 0,
  "connections": 12,
  "proxy": "",
  "difficulty": 0.2833186345714879,
  "testnet": true,
  "keypoololdest": 1518115544,
  "keypoolsize": 1001,
  "paytxfee": 0.00000000,
  "relayfee": 0.00010000,
  "errors": ""

"Command": "getboincinfo",
  "CPID": "4fd1bf6c6900d92b226e16c6a6935661",
  "Address": "yWQfYmBCAQrcn9RkjM9DJwWGfgjHdvpZwn",
  "CPIDS": "4fd1bf6c6900d92b226e16c6a6935661;",
  "CPID-Age (hours)": 422068,
  "NextSuperblockHeight": 6732,
  "NextSuperblockBudget": 1359680,
  "4fd1bf6c6900d92b226e16c6a6935661_RAC": 820.6,
  "4fd1bf6c6900d92b226e16c6a6935661_TEAM": 15044,
  "4fd1bf6c6900d92b226e16c6a6935661_TaskWeight": 0,
  "4fd1bf6c6900d92b226e16c6a6935661_UTXOWeight": 0,
  "Total_RAC": 820.6,
  "Total Payments (One Day)": 0,
  "Total Payments (One Week)": 546564,
  "Total Budget (One Day)": 13700330,
  "Total Budget (One Week)": 67535384,
  "Superblock Count (One Week)": 63,
  "Superblock Hit Count (One Week)": 49,
  "Superblock List": "6633,6534,6435,6336,6237,6138,6039,5940,5841,5742,5643,5544,5445,5346,5247,4653,4554,4257,4059,3861,3762,3267,3069,2970,2871,2772,2673,2574,2475,2376,2277,2178,2079,1980,1881,1782,1683,1584,1485,1386,1287,1188,1089,990,891,792,693,594,495",
  "Last Superblock Height": 6633,
  "Last Superblock Budget": 1359680,
  "Last Superblock Payment": 0,
  "Magnitude": 8.09300203283067


I know this is going to sound a little complicated.. and Im thinking of ways to simplify this but with advanced system comes some advanced business logic:

The getboinc info values are current as of right now, so this is what Your client feels your RAC and your UTXOWeight and your TaskWeight are right now.  However, it takes a while for those to propagate through into the Sancs memory.  Because the Sanc has to allow 6 confirms for utxo weight in order to trust it and memorize it (it memorizes each cpids utxo weight into memory with a global key, called CPID_UTXOWeight_ with a 24 hour deadline on the timestamp, where new stamps erase old stamps, so its a complicated thing to explain).  This way all sancs are memorizing the utxo weight and task weight at the same time - all their memories should be equal.  They actually vote on what *they* agree on.

Now the Magnitude in getboincinfo is actually your reverse engineered magnitude over 7 days period. 
Your Superblock magnitude however , seen in exec leaderboard, is actually your "realized" mag as of the last superblock.

So from a cosmetic point of view, Im working on homogenizing this to just give the average biblepay-qt user a few numbers to look at on the GUI.

For the techies though, this means:  Your getboinc info is current debug info, but what the sancs vote on (they are always voting on the Next contract) is slightly different, as their memories are lagging slightly.

To see what a sanc *will* be voting on, go to one of your sancs and type exec testvote.  That particular contract can be dissected to see what they see about the network.