Concept POOM

Proof-of-Orphan-Mining

By: R Andrews

Date: 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 API of 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 in 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, central-government 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:

The orphan API is broken into two parts. To respect the privacy of the individual miner, only the minimum is queried per nightly scrape at compassion.com. The orphanstats.com website will have a service running. The service will iterate through each users public key, and will access the POOM miners compassion account, pulling: Miner Sponsor ID (this is a compassion identifier, a number), Each Global Orphan ID (this is a distinct orphan ID, a number), and monthly commitment amount. Then the service will log out. The service will then on its own, query compassions Public API for: Orphan BIO URL, Child Age, Child Sex and Child Name. The system will then update each orphan record with this additional information, so that our API ability is richer.
We will then expose a Restful Orphan API for use by supporter sites and by BiblePay Core.

Orphan Magnitude, Payment Amount, and Algorithm:
Since POOM competes with PODC, any reward paid to POOM sponsors comes out of the total PODC daily "kitty". The following algorithm illustrates how a users payment is calculated:
SPONSOR_MONTHLY_COMMITMENT_AMOUNT / (TOTAL_PODC_RAC / SPORK_AVG_MODERN_PC_RAC * SPORK_MONTHLY_ELECTRIC_RATE_FOR_PC) * 1000;
This yields the "orphan magnitude". The orphan magnitude is appended into the Daily contract creation process for PODC - meaning that the orphan miners are taking a share from the PODC budget to be rewarded for Orphan mining.
As an example, if one miner sponsors Three children at $38 per month, this yields a $114 monthly commitment. This yields a magnitude of 3.0 at todays total team RAC of 8,000,000 which is approx. 90,000 bbp per month - subsidizing the orphan miner.

Chain Block Integrity from a Greenness perspective: This payout method supports a virtually unlimited number of POOM miners (or PODC miners) since the daily superblock is leveraged for each payee. From a greenness perspective, what this means is a POOM miner who takes a share of PODC is actually offsetting electricity costs directly. This is because the PODC budget is reduced, causing less participation on the science side. The green poom miner may optionally run the controller wallet, but as covered in our prior discussions, the controller wallets mining with POBH are running one thread and hashing slow (as compared to PODC mining). This means that a POOM miner is in reality 90+% greener than a PODC miner and the financial renumeration method is 100% efficient. In summary, this proposal directly diverts electricity based mining to POOM reward repayments.

Summary:
If this infrastructure is in place, it offers the end user the ability to be compensated for sponsoring home orphans, makes us greener, and bigger. This could be the impetus biblepay needs to make it into the mainstream. With an orphan collage of 500 monthly orphans, every exchange will take us seriously, and we will truly be extending Jesus Kingdom.

From a cosmetic standpoint, we could simplify the new user experience, with the goal of Plug-and-play. In the most simple sense, this could be achieved on one page: The user sponsors an orphan at compassion.com, downloads the wallet, creates an account on orphanstats, saves the private key, clicks one button to 'Set Up Mining' at home on the core QT wallet, this registers the POOM transaction in the chain, and no further setup is required. (This today, requires at least 1bbp, however we do still have the faucets). In theory this would result in fast adoption, and therefore growth of our community. For all users who want a simpler onramp.
Where is IPFS in all this? Due to this idea having the highest altrustic value, I recommend we pursue the aspects of this proposal, and not kill IPFS, but instead, leave IPFS in a volunteer state. This proposal illustrates how orphan letters would not be stored in chain. IPFS can still be maintained on a volunteer basis for business object records (revenue and expense). We can revisit IPFS at a later time.

Budget interference:
In this proposal we do not interfere with the charity budget, IE we leave it for future use - or we vote to reduce it, but my current recommemdation is that we reduce centralized charity expenses to zero over time so as to not transfer any tax-risk to our volunteers. IE we could phase out the centralized compassion account over 6 months, move to this decentralized system, and reduce the charity budget to 5% - leaving it in for future possibilities. We also must remember that BLOOM and Kairos do currently accept BBP, so we must consider keeping a budget level available for those accepting BBP for Charity.