Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Rob Andrews

Pages: 1 ... 234 235 236 237 238 239 240 [241] 242 243 244 245 246 247 248 ... 277
3601
Shows 100 for UTXOWeight now!
Hey btw what block number was your PODC update in?  I noticed you were running a massive number of tasks, like hundreds.
I need to see what your CPID did to our block size?


3602
Shows 100 for UTXOWeight now!

Its good to know you have 311 mag right now, as of the last post, thats because we were in dr mode 3 prior to the upgrade.

(The system finds your mag from the last solved superblock).

  But please, post it for us after block 5346- Im curious what you jump up to.
You should jump higher since only 3 of us have 100% integrity currently.


3603





Code: [Select]

  "Command": "getboincinfo",
  "CPID": "93138f032bdd027fa3246b48bb715a77",
  "Address": "yjUmY8EmuSKf6EWJf4aajWovksV2TQbxWc",
  "CPIDS": "93138f032bdd027fa3246b48bb715a77;",
  "CPID-Age (hours)": 422035,
  "NextSuperblockHeight": 5346,
  "NextSuperblockBudget": 1380386,
  "93138f032bdd027fa3246b48bb715a77_RAC": 7229.4,
  "93138f032bdd027fa3246b48bb715a77_TEAM": 15044,
[b]  "93138f032bdd027fa3246b48bb715a77_TaskWeight": 0,
  "93138f032bdd027fa3246b48bb715a77_UTXOWeight": 0,[/b]
  "Total_RAC": 7229.4,
  "Total Payments (One Day)": 725112,
  "Total Payments (One Week)": 15047816,
  "Total Budget (One Day)": 4141158,
  "Total Budget (One Week)": 48313510,
  "Superblock Count (One Week)": 49,
  "Superblock Hit Count (One Week)": 35,
  "Superblock List": "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": 5247,
  "Last Superblock Budget": 1380386,
  "Last Superblock Payment": 0,
  "Magnitude": 311.4618664634385

ok looks like TaskWeight went from 0 to 100 but UTXOWeight still at 0

Is there anything I have to do for the staking/UTXO part?


Hmm,

Maybe you didnt wait long enough, please try exec getboincinfo now, does it show 100 for utxoweight now?

Looking at the list:


13:21:20

Code: [Select]

exec datalist utxoweight


13:21:20

{
  "DataList": "UTXOWEIGHT",
  "04FBA56D89A5EB38B1B82F8A6240132C": "",
  "4FD1BF6C6900D92B226E16C6A6935661": "",
  "6785DED1F65063EF8F01F42DEB31CF1D": "",
  "71F1F1F46DEB2F25961C7D9AF06F2B31": "",
  "8735CFE64D964416DBA6015EB414CF7E": "",
  "93138F032BDD027FA3246B48BB715A77": "100",
  "95A79CD5829E8315B0B946709930DF18": "",
  "C9085154B7CC0CA2B5189672559DD6D8": "100",
  "CA895B47AACFFBDBF906201821AF2F9F": "100",
  "CC37D0EF74A621379974484F43D3B1C5": "",
  "D9B22FCCFAE5582D4EE7838883AAA3CF": "",
  "E7AE6ABD6284B05F3FD5F7C780E60BC7": "",
  "E94C1704C75F731F8BFDE303F08408EE": "",
  "F80AB050AB53459EC937879A046D603E": ""
}

Looks like you are 100% now.

Let me run the commands to check our next pending block.

Oh btw, when you post long pastes, please surround them with the "[ code ]" and the "[ / code ]" so they look shorter - thanks man.


EDIT:

Ok, it looks like you are going to be fine, here is a secret, to find out what the next superblock is going to look like, run the exec testvote, and extract the contract row starting with your cpid like this:
93138f032bdd027fa3246b48bb715a77,597.312,1981221,15044,100,100,11999\n

Notice the last 4 fields: 15044 is your team, 100 is your utxo weight, and 100 is your taskweight, and 11999 is the team total verified task RAC.  This is what composes your magnitude.  So now I know your magnitude will be changing on this next block.  Let me see when that hits.

Your magnitude should change right after block 5346 is solved.  So you can run exec getboincinfo now, and you probably have your last magnitude based on the old DR mode.   Then check the magnitude and paste after 5346 is over. 

3604
Okay removing the chainstate and blocks folders and the .dat files and doing a reindex worked,
both testnet sanctuaries synced now, and Im running 1 miner thread on the one with the CPID burn

./biblepay-cli getblockhash 5291
e85566fcf7a1f2da10af68206543aa2270568c725903f56293ba1bf9d7190556

Great!  To jump start your node without waiting 4 hours type:
exec podcupdate

Wait 6 blocks (til the podcupdate tx is ticked) , then type exec getboincinfo and see if your TaskWeight=100% and your UTXOWeight=100%?

If so that means the researcher will receive the Full reward.


Btw, in heavenly mode, thats the mode we are in now, we are in DR Mode == 0 (Heavenly) currently, Magnitude = TaskWeight * UTXOWeight * RAC.


3605
Awesome, so just to summarize:
We will have to have our controller wallet (the wallet with the CPID Burn link) be on 24/7 mining at 1 thread?
We will need 50,000 BBP in the controller wallet to receive max research rewards?


./biblepay-cli getblockhash 5260
1fbe3bcb4325233dd43aa6eefa46c22c966ad1e6e5420e022956cb33caf16d7f

./biblepay-cli mnsync status

  "AssetID": 1,
  "AssetName": "MASTERNODE_SYNC_SPORKS",

Im still masternode syncing, but not seeing attempts, weird, Ill report back later

Yes, your controller wallet with the associations would have to be the one to stay on so it can send the podc updates.  It sends one every 4-8 hours (spork TBD still), but only if task updates have changed.  Note for people with more than one CPID, it sends one PODC update PER cpid per frequency.

As far as the 50K requirement, thats generally correct, but the stakeminer tries to use .05% of the balance unless you set POLpercentage=50 in the config. 

As far as syncing, please try to rebuild the chain after deleting mn*.dat. 

One nice side benefit we will reap is the controller wallets will be on for more pobh security 24/7.


3606
So, our PODC system is becoming pretty huge, and its obviously adding inrinsic value to Biblepay for the long haul.

We have a lot to test and a lot to explain.

First,  please see the changes I made to the wiki page on distributed computing:
http://wiki.biblepay.org/Distributed_Computing

Search for the "Biblepay UTXO Reward Chart".
Once you find that, please review the utxo reward chart and the Task Integrity reward chart and the Disaster Recovery Modes chart.

Hopefully those charts will explain the primary changes.

Let me go over the primary changes:

- Researchers are required to be on Team Biblepay for the researching credit to count.
(Support personnel can point the user to exec getboincinfo, look for TEAM: 15044, and if the researcher CPID is missing from the team they will see a warning).

- It is required that the controller wallet be running mostly 24/7, in order to be paid for research.
We now have a metric per cpid called "Task Integrity" (Its called TaskWeight in getboincinfo).  This is a percentage from 0-100% and is based on the integrity level the sanctuaries have assessed your CPID with.  If for example one CPID is working on 10 tasks, if 2 of those tasks are found to be tampered with- the task will not be counted as part of the integrity level.  If no task updates are transmitted from the controller wallet, No rewards are given to the researcher.  This means for now, you must run the controller wallet 24/7.  See the Task Integrity chart for a breakdown on the snap-to-grid reward percentages.

- You must run at least one thread in the controller wallet miner.  Setgeneratetrue = 1 or greater.  Otherwise biblepay will not transmit the PODCUpdates to the blockchain.

- The PODCUpdate transaction can be seen from the txlist.

- Inside the PODCUpdate, we send a coinstake "stake amount".  This ties the tasks that CPID is working on with a UTXO output, and also the CPID signature is required.  Depending on the level of stake, your magnitude is adjusted.  You receive a "UTXOWeight" value from 0-100%.  See the UTXO Weight chart to determine your place on the chart.  (Note, if the controller cannot sign with the CPID, no credit is rewarded for the UTXOWeight or the TaskWeight).

- Exec getboincinfo will also show the UTXOWeight and TaskWeight levels.  This will be useful in diagnosing issues to find why payments are not being received.

I know some people will view this as: Why have we made it so complicated to research?  However, the upside to these changes, proving each UTXO belongs to a researchers tasks at a given point in time is of far more benefit.  It will also provide higher rewards to those who maintain the  infrastructure properly.




3607
1.0.9.4b - Mandatory Upgrade for Testnet

- Add PODC Integrity system to core wallet
- Require controller wallet to send task updates into the blockchain
- Require Sanctuaries to Verify Rosetta Tasks
- Base Magnitude on UTXOWeight, TaskWeight and RACWeight

* Windows is compiling now *

3608
I understand your frustration Rob. Slovakia is quite the character, and I think he must have used up most of the '77 times' by now  ;D

LOL, Hes getting there.

3609
Its a mistake, it should be Intl, let me see if I can fix it now.

This had to be escalated to the top.  I entered a ticket for it - and they closed it.  I emailed David Anderson.

3610
No problem.

By the way, I don't think it's very loving to say "get lost". I understand your frustration though.

He said We were all here for Greed, and alluded that this project is about money and were not really Christians.  Your right, I should have replied with more Love.

If you look at the history, I have tried that, and God actually says to forgive your brother not 7 times but 77 times.
I do forgive him....


3611
I didn't start the other nodes today because it looks like there will be an update soon.

Good point.  Yeah, its very, very close.  Im testing it on my LAN now.  Im not sure if it will be ready tonight though...


3612
Thanks. And small detail to the future. I think, that will be fair that Biblepay team country on Rosetta should be "International", not "Canada". And why is it Canada? :)

Its a mistake, it should be Intl, let me see if I can fix it now.


3613
Rob, to the small fishes :)
My Nexus 4 testing is going really great. Just for imagination my RAC on that device is 280 ;) Of course it runs almost 24/7.
https://boincstats.com/en/stats/-1/host/detail/333426255/lastDays
Oh... to the data consuption... In those 6 days it spent approx. 1GB.

Ok, thanks, let me take a look at what the sanctuary can find out about the host.  We should definitely consider allowing tablets and phones without any extra work from the controller. 

3614
Rob whatever you fixed in latest commit fixed issue I had on my one of my linux sanctuaries,
folders and .dat files deleted, I couldnt get it to reindex, it would be stuck at block 0 for a little bit and crash, works now!

Great!

Yes, we had at least 2 bugs, and Im a little happier when I see the reason for them instead of programming around the issue until we drop.

The first bug, the reason we couldnt sync from 0, was due to a 2 digit rounding error in the old contract.  I found out that the grand total magnitude with 25 researchers, out to the 2nd digit in scale was 1000.03, which created an attempted overpayment, and due to the grandfather rule we synced over that block but it "covered" up the problem.  Now the system shoots for a 998 magnitude, and uses 3 digit scale, so that appears to have solved the syncing issue permanently.

I have a lot of code coming today so we wont be in this lull long.  Ive been working on the integrated integrity feature.  I truly think if we can reconcile the rosetta work with utxo's, we will be the first coin to have trustable PODC.  PODC that exceeds the righteousness of the Pharisees and scribes, just kidding.  No PODC that exceeds the trust of POS, because POS is based on UTXO (unspent outputs).

So with greater integrity comes a greater workload for the controller wallet and the sancs, that means more propensity for clerical errors or should I say technical errors in the sancs.  For example what if a sanctuary fails to verify one task out of 100, due to a vultr network tcp error, I would hate to throw the entire contract off (meaning our SanctuaryQuorum would fail and no one would be paid).  And that would happen if one unverified task lowered a researchers task integrity level from 100 to 91.123 and other sancs felt a different way about various researchers.  The other one is UTXOWeight, although Im not worried about that as much, because it will always verify correctly, but it needs to established that the window of UTXOWeight must be exact, for example if one researcher sent 2 UTXO's in 8 hours of PODC updates, in 24 hours period, then the Sanc creating the contract must have an exact start-endtime snapped into the grid as well. 

To handle this, Im creating a UTXO Weight breaks chart.  This means researchers will receive a Percentage reward based on the UTXO Stake Amount inside the PODC update from a chart, with relatively large breaks.  Something like 1-50000 BBP is in the chart, (the chart ends at 50,000 bbp max to not give much advantage to whales), and we have a break every 10000.  This means only 6 allowable reward levels: 0, .2, .40, .60, 1.00 Etc.  This way the contracts will tend to "jive" across all sancs.  Im doing the same thing with the Task integrity system - the validated tasks as compared to total researcher tasks will snap to a grid, so that the user receives a percentage float result based on .20 breaks.  I think what happens in the end is everyone is assessed with 3 values per day that comprise ones magnitude:  UTXOWeight (0-100%), TaskWeight (0-100%) and RosettaRAC (Current RAC from Boinc).  We multiply your UTXOWeight*TaskWeight*RosettaRAC to arrive at your magnitude while preprocessing the file.  These levels will allow us to write an exportable excel report with trustable integrity per day with actual provable details per researcher.  (If for example Rosettas SQL DBA is being held up at gunpoint after one of our timestamps, it will disrupt the integrity of those affected researchers due to timestamp manipulation).

Finally, I am adding sporks for system enabling of the UTXOWeight, and TaskWeight as distinct features.  This allows us to shutdown those two features and revert back to plain vanilla PODC in case something goes haywire in prod.  The most common thing I can think of is not that UTXO "blows up", but that the Task Validation system malfunctions - possibly because the boinc servers are down while Rosetta is up.  Im thinking if something in the public interface changes, for example, if boinc shoots out emergency updates that break compatibility with biblepay, we can shut off TaskWeight with a spork, and still survive in our old plain vanilla PODC mode (daily RAC rewards) until that other piece is fixed again.  So we would have more granular survival levels:  Plain PODC, PODC + UTXO + TaskAudits, or POBH mining only - etc.



3615
Alright, windows 1093 is out there, now lets try to increase our Sanc count to ensure all sancs sync to 999.

Pages: 1 ... 234 235 236 237 238 239 240 [241] 242 243 244 245 246 247 248 ... 277