Distributed Computing

From BiblePay Wiki
Jump to: navigation, search

Proof-of-Distributed Computing

Use Case

Proof-of-Work Mining generates heat but does little useful work, because its primary activity is searching for a numerical block hash lower than a target hash, and this resulting block provides a network consensus and security (IE this block becomes the most recent block on record). However, this leads to an ecosystem where a massive amount of electricity is consumed and the algorithm performs little useful work.

A greener alternative to proof-of-work mining is proof-of-distributed-computing, a relatively new consensus attempt, already being used in various coins to a limited degree. Most coins that attempt this type of consensus end up with some systemic problems that hamper their growth. It is Biblepays desire to address all of these and overcome them, and use proof-of-distributed-computing as our primary consensus algorithm so that we may perform a useful function in exchange for the dormant clock cycles on our users machines.

In addition to this, we are a community that provides sponsorship for Orphans, and we are committed to following Jesus' examples. He teaches us to love one another, help one another, and to heal in his name (Acts 5:12, people were brought into the square, so Peter's shadow could potentially touch them, and the Apostles learned to lay hands on the sick and Heal them). What more of a noble effort than to try to cure cancer? We are teaming up with Rosetta, and David Baker from Baker Labs, and will dedicate our computers to curing cancer - with Rosetta@Home.

In the future, Biblepay may support more than one Distributed Computing application if it is compatible with Healing. To start off in a straightforward manner, we currently only support mining with Rosetta@Home. However, we are carefully writing our wallet to include generic compatibility with multiple concurrent distributed computing projects.

Researcher Association

A researcher is an individual who is actively participating in one or more research projects, while (the sub-processes of that project) are executing on one or more physical computing devices.

Each researcher receives one unique ID called a CPID (Cross-Project-Identifier). See more on CPIDs.

This single CPID links one researcher to many devices. If a researcher has 100 PCs analyzing Rosetta@Home concurrently, the researcher still has ONE CPID.

This section describes the process of associating the Researcher CPID with a Biblepay wallet.

To make this convenient, ONE CPID is associated with ONE biblepay public key, so the user may migrate one wallet.dat for life.

Adding more Keypair associations will only complicate the setup for the researcher.

To associate the BiblePay Public Key with the Researcher CPID, Biblepay uses a Distributed-Computing Burn Transaction.

This is a one time transaction sent from the researchers biblepay wallet into the block chain, containing the : CPID, Biblepay public compressed key, Nonce, Signature, and a public Hex TXID that may be read temporarily by other nodes who will want to verify the users membership assertion.

Once transmitted, every biblepay node attempting to mine the burn transaction will verify the ownership of the CPID.

If the verifying node finds the Hex TXID value inside the BOINC account referenced, that verifying node will add the Burn TX to its memory pool, otherwise it will discard the transaction.

In this way, only verified accounts will be allowed to be persisted in the chain, therefore, the list of researchers inside biblepay will be accurate, succinct and verified.

GUI Researcher Association

To associate the Researchers CPID with Biblepay, perform the following steps:

  1. Ensure you have an account with Rosetta@Home, and a CPID
  2. Launch Biblepay-QT
  3. Click on the Distributed Computing Association Tab from the home page of the wallet
  4. Populate "Rosetta@Home" in the Project Name by choosing it from the drop down
  5. Populate your Rosetta@Home UserName in the UserName field
  6. Populate your Rosetta@Home Password in the Password field
  7. Click Associate

The wallet will NOT keep your Rosetta credentials (as can be seen in the opensource code).

It will create a Burn Transaction with a Hex one-time-use code, and it will place the Temporary Hex Code inside your Rosetta account, using the credentials you provided, then it will destroy the credentials.

You will then see the BBP TXID of the burn transaction.

At this time, all other biblepay nodes will verify your account by "viewing" your account Hex Code, and comparing it to the Burn Tx Hex Code.

If they match, they will Mine your transaction into the Chain and then your CPID will be associated permanently with Biblepay! Thats It! Congratulations, you are now a Cancer Researcher Helping Bibleay Cure Cancer!

Peer Review

Robert Andrews, Founder, is currently writing a White Paper on Proof-Of-Distributed-Computing, and evaluating the core algorithms with the chair of network security for Ruhr University, (Martin Grothe). When complete, Rob will publish in Professionals of Grid Computing in the Journal of Grid Computing, Communication Networks for peer review.

Rob will then recommend the paper be reviewed by David P. Anderson, PhD, Computer Sciences, UC Berkeley Space Science Lab, creator of Berkeley Open Infrastructure Network Computing Grid.

Disaster Recovery Mode

During periods when the Biblepay network is UP, but for unknown reasons a distributed-computing-consensus cannot be achieved for accurate researcher credit levels, Biblepay will continue to function in the following way:

Biblepay will revert back to Proof-of-loyalty mining and Proof-of-Work mining. In this way, Biblepay will never go down if BOINC or Rosetta@Home goes down.

Sanctuary Credit Harvesting for Sanctuary Quorum

Once every 200 blocks (this is once per day), each Sanctuary will check to see if it has an active DC Superblock. If it does not, it executes the DC Credit Harvest process.

Once the Sanctuary has a DC Contract, it checks to see if a DC Contract Gobject Exists for that hash. 10% of the active sanctuaries will download a personal copy of the Distributed Computing Contract from Rosetta. Each sanctuary will filter the file down to Biblepay only researchers. Then they will be sorted and normalized for 0-100 magnitude levels (with 0 being no research is being done, 100 meaning that researcher is doing the most work). Then the file will be rewritten as the DailyMagnitude file. This will be converted to a contract in biblepay and hashed. Each of the chosen sanctuaries will vote on this hash.

Once the contract has more than 50% of the chosen sanctuaries Yes votes, the sanctuary will store the contract in the memory pool and stop voting on it. (This is to alleviate DDossing BOINC/Rosetta computing grid resources).

The sanctuaries will then sleep until the next superblock. When the DC superblock is due, a normal miner will query the Sanctuary Quorum for the distributed computing voted file. At this point, it will be appended to the superblock and a superblock will be generated with designated researcher payments in it. In this way, Biblepay will support unlimited scalability in the future. Biblepay does require that a Rosetta researcher joins Team BiblePay.

The sanctuary signatures will all sign the superblock, so that the sanctuary sigs may be verified by the entire network (so that block checking does not fail). The researchers are paid in a way that the allocated daily budget is split among them by their individual magnitude, so no chance exists of overpaying BBP in the superblock. The grand total must not exceed the budgeted level for distributed computing.

Then the Sanctuary will Submit this DC Superblock Transaction to the network.

The Superblock Transaction contains a list of : CPID, Biblepay Public Compressed Key, Researcher Magnitude, Amount. At the end: The sanctuary votes and signatures.

The individual nodes will verify the sanctuary signatures, and if the DC Superblock Hash matches (the hash with supermajority votes), and if the sanctuary signatures are valid, the superblock will be accepted by the network.

Proof-of-Distributed Computing

The Biblepay consensus algorithm will be extended to honor the Proof-of-Distributed-Computing algorithm, to allow a hybrid consensus of:


Proof-of-Loyalty (DISABLED)


The Proof-of-Bible-Hash algorithm is a flavor of Proof-of-Work, requiring a miners bible-hash to be Lower than the nBits extrapolated value. Proof-of-Loyalty is a flavor of Proof-of-Stake, in that the amount of coin*age you carry raises the allowable extrapolated target hash (making it possible to solve a block on a cell phone, given enough coin*age).

Proof-of-Distributed-Computing Payment System

Each cancer researcher will submit results to Rosetta@Home which will increment their Total Credit. The Recent Account Credit is influenced based on the half life of work done in the last two weeks. Biblepay monitors the Recent Account Credit per researcher and makes payments based on that level.

First, after filtering the daily DC computing credit file down to Biblepay participants, we sum a grand total RAC across all participants. Then we assign a Magnitude to each researcher from 0-100 (with 100 being the researcher doing the most work).

The payment system pays out 90% of the available block subsidy to proof-of-dc, and 10% to proof-of-loyalty/proof-of-work.

Assuming that a budget of 100,000 biblepay exists in a given day, if we have three researchers that day, one with a magnitude of 100, one with 50, and one with 10, the payment would be as follows:

Researcher Magnitude Amount
A 100 62,500
B 50 31,250
C 10 6,250
TOTAL 160 100000

PODC Updates

PODC Updates are designed to add integrity to the PODC Consensus system, tying a Rosetta task to a wallet UTXO for one CPID and one Biblepay address at a point in time, while the researcher is working the task. The Task itself is checked by a sanctuary, the sanctuary verifies the task start time equals the purported task start time. This process is used to prevent SQL credit tampering on the Rosetta side. Additionally it provides integrity to PODC in that we prove that an actual owned unspent coin output owned by the researchers wallet is indeed signed by the CPID and therefore that particular wallet who owns the coin also owns the CPID, the computer, the account, and is responsible for finishing that single task. This allows Biblepay to write detailed reports showing details per researcher per day, to account for Recent-Average-Credit and Magnitude rolled up to the CPID and its corresponding throughput metrics.

The PODC Updates are sent out as a transaction from the researcher to the researchers CPID public key address, with a coinstake spend amount equal to the configuration key 'utxoamount=YYYY' found in the biblepay.conf file. In this way, the researcher proves coinstake confirmation age > 6 at the time the task was announced. This UTXOAmount influences the users UTXOWeight and therefore the corresponding magnitude and reward level.


The PODC updates are sent either when Manually triggered with (exec podcupdate) (this is for debugging only), or when the core wallet sends one from Thread Zero of the miner.

In order for automatic PODC Updates to work, you must leave your controller wallet (with DC association), mining with a genproclimit=1 or higher, and your HPS in getmininginfo should be above zero, and there should be no errors in poolinfo1 (IE no CPID signing errors present).

Ensure the wallet is unlocked, or optionally started with a valid password (entered in the modal PODC Password Prompt during boot).

Since PODC is scalable, the two following backoff parameters are Network Configurable (they may change dynamically when more than 16384 concurrent researchers are in Prod) but for all intents and purposes the current values are:

  1. MinTime = 4 HOURS
  2. MaxTime = 24 HOURS

PODC Updates are sent automatically when:

  1. Miner is running with HPS > 0
  2. Outstanding Rosetta Tasks have changed and more than MinTime has elapsed
  3. More than MaxTime has elapsed

The PODC Update system will automatically update both the Researchers Tasks (for TaskWeight) and the Researchers UTXO Weight in one transaction.

RAC - Recent Account Credit

The RAC is a decay function based on half life of recent credit earned in BOINC for a particular Computing project.

Biblepay UTXO Reward Chart
UTXO Level UTXO CoinStake Amount Percentage of Reward
Level 0 0-1 BBP per 1 RAC 0%
Level 1 1-3 BBP per 1 RAC 10%
Level 2 3-5 BBP per 1 RAC 20%
Level 3 5-7 BBP per 1 RAC 30%
Level 4 7-9 BBP per 1 RAC 40%
Level 5 9-11 BBP per 1 RAC 50%
Level 6 11-13 BBP per 1 RAC 60%
Level 7 13-15 BBP per 1 RAC 70%
Level 8 15-17 BBP per 1 RAC 80%
Level 9 17-19 BBP per 1 RAC 90%
Level 10 19+ BBP per 1 RAC 100%

Biblepay Task Integrity Reward Chart
Task Integrity Level Task Integrity Percentage of Reward
Level 0 0 0%
Level 1 1-25% accuracy 25%
Level 2 26% - 50% accuracy 50%
Level 3 51% - 60% accuracy 60%
Level 4 61% - 75% accuracy 75%
Level 5 76% - 100% accuracy 100%

Biblepay Operational Mode Chart (Disaster Recovery Modes)
DR Level Algorithm Name Calculation
Level 0 Heavenly UTXOWeight * TaskWeight * RAC
Level 1 Possessed by Tasks TaskWeight * RAC
Level 2 Possessed by UTXO UTXOWeight * RAC
Level 3 The-Law RAC = Magnitude
Level 4 DR (Disaster-Recovery) Proof-of-BibleHash Only (Heat Mining Only)


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.

"Command": "getboincinfo",

 "CPID": "f80ab050ab53459ec937879a046d603e",

This is the Primary CPID of the researcher, used on the overview page and for future cosmetic features. It does not restrict a users payments down to one CPID, but it lets us do things with it like the iPhone does (Sleek features).

 "Address": "yjKEf6GvMkuiXLXibCCtj9wt4ZEBwQ5i84",

This is the public bbp receive address associated with the CPID - this is also where rewards will flow into.

 "CPIDS": "e94c1704c75f731f8bfde303f08408ee;71f1f1f46deb2f25961c7d9af06f2b31;95a79cd5829e8315b0b946709930df18;c


This is a list of CPIDs, if you have more than one CPID associated with this wallet.dat. We iterate through this list in superblock payments to make sure you get full compensation.

 "CPID-Age (hours)": 421821

This is how many hours your CPID has been alive. This is useful if you are brand new and waiting for first reward. We can then show messages like newbie warnings.

 "NextSuperblockHeight": 9207

This is when the next payment is scheduled.

 "e94c1704c75f731f8bfde303f08408ee_RAC": 450586762905843

Here, we loop through each of your CPIDs, notice the prefix, and we tally your individual RAC per CPID. This number should match the BOINC rac on the Rosetta row in the advanced view or in the web portal.

 "f80ab050ab53459ec937879a046d603e_RAC": 50242464
 "Total Payments (One Day)": 17568

This is how much BBP you received over 24 hours for researching

 "Total Payments (One Week)": 1394916

This is how much over one week

 "Total Budget (One Day)": 2730420

This is how much was available in the budget for 24 hours for researching

 "Total Budget (One Week)": 55107360

This is how much budget was available in 7 days for researchers

 "Superblock Count (One Week)": 68

This is the count of PODC Superblocks that passed in one week, whether filled or not filled

 "Superblock Hit Count (One Week)": 41

This is the number of PODC superblocks that had research payments in them in one week.

 "Last Superblock Budget": 1386000
 "Last Superblock Height": 9108
 "Last Superblock Payment": 30879

This is the amount you were compensated in the last superblock

 "Magnitude": 25.3126

Finally this is your magnitude, which is YourRAC/TotalProjectRac * 1000

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.

exec sins

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


What happens to duplicate DCC Associations

Last wins

What prevents CPID heist?

True owner must type in Boinc credentials to associate CPID with Biblepay

How am I compensated if I run 50 machines with Rosetta and One CPID?

Boinc credits are summed across machines, total RAC is aggregated to CPID, BBP records aggregated RAC

What happens if my CPID changes

You may re-associate the new CPID with the existing BBP key and rewards will resume the next day

Am I compensated for historical work?

You are compensated for the last 14 days of work, if you are an existing Boinc user.

Do I need to run Biblepay wallet on every Boinc Node?

You only need to run Biblepay on one node, and it does not need to be the research machine.

What if a rogue programmer takes over the Rosettas server, can they steal BBP credits?

No, they can only disrupt the magnitude levels for each researcher if they compromise the Rosetta database. However, the attack would affect each CPID in a relative way. Since we gather credits and create magnitude relative to the project total, it is not possible to take all the credit into one CPID as we have checks in place enforcing minimum and maximum participation levels.

If a distributed computing project Is taken over by a hacking entity, will biblepay just continue to pay invalid researcher amounts and be held hostage?

No, if this happens Biblepay Devs will issue a spork to disable the offending project. This will put Biblepay in Proof-of-work/proof-of-loyalty mode.

Can a user falsify another persons Distributed Computing CPID and hijack their rewards?

The Association process requires the user to Prove ownership of the CPID, so therefore they cannot associate their BBP address with anothers CPID.

Can a user forge a superblock, create fake magnitudes and force the block in the chain, so that the entire network pays that user an unfair reward?

The superblock will not be accepted because it must be voted on by a minimum of a net 10% of the sanctuaries, and signed by those sancs. Also each sanc processes an ndividual private file and then publishes the hash using the DCC proposal process, once per day.