Difference between revisions of "Continuity Plan"

From BiblePay Wiki
Jump to: navigation, search
(Created page with " Date: April 24th, 2020 ''' Implementing a true DAC ''' Although BiblePay is fairly decentralized, there are a few elements inside BiblePay that Rob Andrews, the founder,...")
(No difference)

Revision as of 19:56, 24 April 2020

Date: April 24th, 2020


Implementing a true DAC


Although BiblePay is fairly decentralized, there are a few elements inside BiblePay that Rob Andrews, the founder, predominantly controls.

Rob has acknowledged that for the coin to become a fully 'decentralized autonomous charity', and in addition, for future continuity plans (to not rely on Rob as a single point of failure), some work has to be done to ensure BiblePay can continue fully if Rob were to drop out of the project, die, or be raptured.

Rob has done an analysis of the code, and proposes the following changes to convert BiblePay into fully autonomous mode:

The changes include: SPORK voting, Exchange pricing source(s), Pools in good standing, Vendors, Vendor Payments, Decommissioning POOM, and github.

Let us first tackle the largest and most important aspect in BiblePay: Establishing orphan sponsorship vendors, establishing vendor payment addresses, voting for a pool in good standing, and entering expense/revenue records.


Orphan Charity Process


1. When the need arises to vet a new charity (such as Compassion.com, cameroon-one, Kairos, or SAI.NGO), the community will choose a reliable member to reach out to the charity org to vet them. They will check the organization to verify they are highly efficient (at least 75% of the revenue reaches the recipient and), they are guidestar gold rated or equivalent, the reputation on search engines does not show them as corrupt, and the meeting went well. Then they will be asked to adhere to technical specifications (will they provide public facing orphan biographies, one for each child, such as here: https://biblepay.cameroonone.org/bios/cb1df8c7.htm), and will they accept XMR by providing an XMR address for services? Then, a sanctuary vote will be held. This vote will approve or deny the charity to be an approved vendor for biblepay. This vote forum thread should contain the public XMR receive address, so it is known, and the results of the meeting (that the vendor agrees to public bios, will accept XMR, and any specifics).


2. Once every change occurs to the BiblePay vendor list, a Sanctuary vote will be entered to approve a "Vendor Spork List Change". This means that you will need a simple comma delimited list of XMR addresses, that are known to go with approved vendors in step 1. For example, Let us assume biblepay has no approved vendors yet in Jan 2021. Let us assume the Sanctuary community has approved: Cameroon-One and Kairos, and, Cameroon-One is known as "88abc1" and "Kairos" as "44abc2" (these are XMR addresses). The community vote should be constructed like this : "SPORK|VENDORS|44abc2;88abc1|Cameroon-One;Kairos". What this means is the sanctuaries are expected to approve payments to go to Cameroon or Kairos XMR addresses; any other orphan payments will be rejected from the chain, and not allows to pass from pools to the vendor. Once this proposal passes the vote (and the proposal is paid), a spork will be updated in the chain automatically enforcing the decision (without Rob).


3. Once every change occurs to the BiblePay RandomX pool list, a sanctuary vote will be entered to approve a "Pool Spork List Change". This means you will need a simple comma delimited list of Pools that are in good standing. Good standing means that the pool has never materially failed to make an orphan payment to the official (voted in vendor list from #2). Let us create an example. Lets assume we have MiningPool.Fun operating for 6 months, and "ShadyPool" operating for 6 months. Neither has ever failed to make the monthly payment to Cameroon-One via XMR end of month transfers. However on month #7, ShadyPool misses the payment. This should trigger a sanctuary Proposal, to propose that we change the "Pool Spork List". You should give Shady Pool at least 15 days to make the back payment first. Then enter the Proposal. The Proposal would include a list of pools who are in good standing. Example: MiningPool.Fun is "44abc9". Foundation Pool is "12cba1". The spork looks like this: "SPORK|POOLS|44abc9;12cba1|MiningPool.fun;Foundation". This proposal will be entered and voted by sancs. Once this passes, the spork will automatically be updated (Without Rob).


4. Rob will modify the core wallet code to honor these new Proposal types, and outcomes. And this code will automatically update the active sporks, autonomously, to honor the sanctuary vote outcome.


5. NOTE: If the sanctuaries vote a pool OUT of the pool list, the blocks solved by that pool will NOT be accepted by the biblepay network. Additionally, Pools should not PAY expenses to XMR addresses that are not in the "Vendor Spork List". Actually, they may automatically pay the chosen XMR recipient from the "Vendor Spork List" (this automates payments from satellite pools to our vendors).


6. Using this method, we have created a governance process that allows: Identifying, vetting, establishing, removing, paying, and enforcing our orphan-charity mission, in a decentralized manner.


Decentralized Price Aggregators

Currently, the core wallet looks for a spork containing the URL that shall provide the current Bitcoin Price, BiblePay price, XMR price and dash price. This is only used for the 'exec price' command (which is only cosmetic at this time). One place the price is actually used is in calculating POOM payments. However, I feel that POOM may be phased out very soon, due to the success of RandomX. Nevertheless, we can decentralize this away from Rob, in the spirit of being a fully decentralized DAO.

1. Sanctuaries may enter a vote for the price endpoint by entering a proposal using this format "SPORK|PRICE|TICKER_TICKER2|Source". This will allow the spork to be changed in a decentralized way, away from our current source (which is SouthXChange via a midpoint buffer). (We use the midpoint of the price (not the bid or ask), and, we cache the price for a couple hours). However, if the community feels the need arises to change it, this allows the change to be voted on and made.


Voting without Rob

1. The situation would occur that if Rob leaves the project, we assume that his sancs will either go off (if he is dead or unable to maintain his sancs), or, a smaller chance that he goes quiet and keeps his sancs running. Assuming his sancs go offline and get POSE banned, at that point it will be easy for the remaining community to vote with a large vote power (the remaining sanc count is what determines the winning requirement, which is a 10% net requirement).


Decentralizing Foundation and Satellite Pools


The foundation c# code (for foundation.biblepay.org) already has a head start in being decentralized. It is written in a way that does not centralize the permissions, authentication, or pool into one single point of failure. The way it is written, it is understood that each pool operator will have a copy of his/her own database. This pool's database will contain the local users balances (so for example, if you hold a balance of 1MM at foundation.biblepay, and then you log into miningpool.fun, your balance will not be 1MM there). Additionally, 2FA authorization works by domain name, so your 2FA code is only good at the DNS location it was established with (ie the mining pool you are using).


However, since Rapture videos and Christian video content take up a lot of space, we have shared "video.biblepay.org" across all pools who want to access that data; and this should add value, although it can be argued that for the future Great Tribulation features, we should further investigate fully decentralized file hosting for media and for anti-censorship causes. We will talk about that endeavor soon.


In summary, it is expected that a few or more pools rise up in a decentralized way, with their own individual pool balances.


Entering the monthly Accountability Record


Once per month, someone needs to enter a single record into the pool for our accountability report. This tracks the amount we spent for charity and raised for charity (see our foundation.biblepay.org | Accountability reports).


When a change is required for the Accountability Administrator List, a sanctuary vote should be added using this format: "SPORK|ACCOUNTABILITYADMINS|User1;User2". This will allow the sanctuary community to change users who have access to add Accountability records. The Username is the 'foundation.biblepay.org' user-name who will enter the record once per month.


The devs will expose a new web UI page this quarter that will allow an admin, who is in the list above, permission to add accountability records. The accountability record works like this: Each Pool will report how much XMR was raised, and how much was sent to each charity address. Let us assume Pool A raised 1.0 XMR and sent 1.0 XMR to Cameroon-One. The revenue record would reflect "pool A", 1.0, "Cameroon-One", "Cameroon-One XMR Address" for expense. And this same record would include revenue information.


This process will decentralize our DAO accountability reports.



Ramping up RandomX for Success


Since we are on track for raising 2.0 XMR in the very first month of RX mining, I feel we should start to prepare changes that will allow us to leverage our position with RX. (Additionally, POOM appears to be relatively not successful for a couple reasons: One, we only have two users who like it. Two, poom still requires liquidations in BBP. Therefore POOM does not appear to be worth supporting, and, it is taking valuable BBP rewards away from the miners).


RandomX on the other hand is rich in orphan rewards that are paid directly by the XMR miners. There is no draw down in our price when we pay our orphanage expenses. Finally, the BBP+XMR paid for mining reduces our total daily mining expenses - when compared to BBP mining alone (XMR covers the electricity costs for the miner, and the BBP is 'gravy').


Because of these dynamics, I propose that we phase out POOM, and ramp up the RX rewards. This is only possible during our next mandatory upgrade.


For June, I recommend that we remove POOM from the wallet, disable the POOM rpc commands, disable the POOM project in our daily GSC, and move the approx. 250,000 in POOM payments made daily to RandomX heat mining rewards (but not to Sanctuary rewards). This will raise the heat mining reward from 2450 up to 3,650 (roughly).


Rob will then ask Cameroon and Kairos to keep the children active, but outside of POOM. We will ask Cameroon and Kairos to provide XMR addresses. Rob will ensure the children are paid through the rest of 2020 (regardless of the ability for RX to pay the entire amount). In 2021, we will regroup and decide if we need to cancel some of the Kairos/Cameroon-One for solvency reasons. In the mean time, we will look for GlobalGiving matches.