Concept POOM

Proof-of-Orphan-Mining

R Andrews

11-13-2018

Abstract: Proof of orphan mining gives biblepay the ability to reward users who sponsor personal children, saves energy (GREEN features), and allows an extremely easy setup for brand new users.

Recently I asked a few friends, who I sent our BiblePay link to months ago, how their experience was in setting up BiblePay (to mine). All of them said the same thing: We installed the wallet but got hung up while installing Rosetta (BOINC). They couldn't grasp all of the technical jargon required to finish the installation (CPID, association, RAC, running a separate miner, etc). In the spirit of simplifying BiblePay, POOM will address this in a ferocious way: We plan on making POOM one-click mining.

The stumbling block for POOM is primarily based in the inability to trust home generated Orphan receipts (IE what if a user falsifies a jpeg of a receipt), or, in convincing compassion to create a custom API for biblepay. This POC (proof-of-concept) addresses both of these concerns, by allowing us in IT to create our own Orphan Intelligence API, and addresses the integrity issues involved.

I have also received some complaints that we may be attempting to tear down something beautiful if we propose to remove PODC (cancer mining). The case for removing it was in the past based on being greener - IE the less PODC mining we do, the greener we are. The idea being that the less we spend on electricity, the more can be diverted toward orphan sponsorship premiums. However, much thought was put into this, and this proposal addresses this also, with a solution that allows PODC "electricity" to compete with POOM "greenness". In this way miners can have the best of both worlds - they may choose science or choose orphan sponsorships.

Mechanics: First, a home user will sponsor as many private orphans as they can afford at compassion.com. (This organization was chosen because they are our biggest charity and have the most IT capabilities for integration with BiblePay). Next, the new user creates a free account with OrphanStats.com. This site will be BiblePay's official Orphan API. In this site, the end user will type their compassion userID, and click a button to create a keypair. The keypair will include a public and privatekey. We will ask the user to store the private key on their machine. Then we will ask the user to update their compassion password to be the privatekey. OrphanStats will then periodically log in (once per evening) and will scan the Sponsor's GID list (Global Orphan ID list), and will only store the GIDList, SponsorID, CommitmentAmount, and will log out. We will have a promise and disclaimer on the site promising that OrphanStats will never attempt to query any other information in a private account.

For Integration with BiblePay: OrphanStats will expose a rich API. Orphan Stats is capable of determining that: No other user may sponsor the same child in a given month, is able to determine the Sex and Age of the child and if the SponsorID is in good standing. All of this will be publically queryable in web-lists, and also available through the API- by querying via the PublicKey. In this way no private information from the original Sponsor is exposed to BiblePay. BiblePay's sanctuaries will Query the OrphanStats Lists via PublicKey.

Payment: Once per day during creation of the PODC contract on each sanctuary, the sanctuaries will be programmed to contain a new process. This new process will ask for a list of "associated POOM sponsorids". The chain will have a deterministic list. This list contains : Sponsor BiblePay Public Key, Sponsor OrphanStats Public Key, Association Date. The sanctuary will then query OrphanStats for the CommitmentAmount per Public Key. The sanctuary will then modify the PODC contract with each sponsors "Orphan Magnitude". This will result in a daily payment back to the Sponsor with the daily reward gained for sponsoring personal children. Heat Mining will also be modified to allow not only a Cancer CPID, but also a POOM-CPID (this is simply the OrphanStats publickey). In this way, a brand new BiblePay user may heat mine with POOM - and receive superblock rewards with very little (to no) setup required once we deploy the one-click setup.

Integrity: We will set up OrphanStats public facing site in a way that shows every private orphan and BIO in a list, so it can be summed and the grand total match the users and amounts. To instill trust we will offer a 1.5 million BBP reward for any corruption found. The basic mechanics of trust tests are: Finding any orphan in the list that is not actually sponsored at Compassion. The SponsorID will be in the list making it possible for anyone to 'check' at compassion if that GID is sponsored by that SponsorID. The other test is to see if any rewards are being given to users who are not sponsoring a child - this one will be impossible, because BiblePay will show the total emission matches the OrphanStats daily GIDList.

Massive Positive Effect for Jesus Kingdom and BiblePay: To understand why this proposal would have a massive effect, one has to consider how much electricity we currently spend in PODC. We currently have a RAC of 8.1MM, meaning that if this was expressed in terms of electricity consumption, it would equal approx. 2000 full size pc's, or $40,000USD per month of electricity consumption! (Based on a 4000RAC average per PC). This is an absolutely stunning amount of potential for BiblePay, the world, Jesus Kingdom, and those orphans. (This is equivalent to 1052 monthly orphan sponsorships). This means that if we divert half of the electricity spent int PODC mining directly to POOM, we could sponsor 500 monthly orphans!

Positive effect for BiblePay as a DAO: POOM mining alleviates fiat liquidation risk and further decentralizes biblepay. It means that each orphan miner takes the personal responsibility to maintain a compassion account and pay it, and biblepay simply reimburses the user. This helps us become stronger, because we have no single point of failure (alleviates orphan-buffer-credit risk, etc).

Simplifies BBP: This system also decentralizes the letter writing. We no longer need to have a central letter writing system to maintain. In addition, each sponsor maintains a better and closer personal relationship to their children.

Orphan API:

Depending on the number of children sponsored privately, the user will have a certain monthly_commitment_amount. If the user is in good standing, some of the things we aim to capture per user (per SponsorID) are: A list of global-orphan-identifiers (GIDs), Orphan ages, Orphan Sex, Orphan Name, and Monthly Commitment Amount. Rob has created a proof-of-concept that illustrates that it will be possible to capture this info from an API.