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.

Topics - Rob Andrews

Pages: 1 2 3 [4] 5 6 7 8
Archived Proposals / The Future of PODC - Proof of Distributed Computing
« on: February 28, 2019, 11:52:58 AM »

Feb 28th, 2019

My what a ride its been in 2018.  (If we only knew everything that we know now, before the beginning of 2018, we would all be a little further ahead in life) - but for me - drawing closer to Jesus is the greatest achievement, and should never be traded for anything.

Going into 2018, I thought I was already experienced, but 2018 redefined that 'assumption' in many ways.  We had lots of things happen in our forums.  We had the huge HODL rise and crash.  I think while we were at our peak of 329 monthly orphans, we also took a lot of credit for this rise as if we - as a community - succeeded at something.  Another words, we should have been monitoring for our own pride and improving - but we let ourselves fall with the HODL fall.  Be very wary of taking credit for achievements -- I believe we were primarily influenced from external forces.  The cryptocurrency market was clearly influenced by Bitcoin and Dashes rise (and fall).

I personally had strong opinions of long held beliefs in certain areas only to be tested, and I've changed my opinion about certain things.  We had our sessions with our focus group (our internal advisors) and our external advisors (an SEC attorney, Manna, outwest advisors, DAHF, etc) and learned that we should be a utility, with a known revenue stream.  That going with DAHF would have pulled us in an anti-God direction.  And that we should add infrastructure to invite a Christian base to use the gospel features.

I'm only saying all of this because I want people to realize that many factors influence the decision of a good algorithm for BiblePay.  It's not that we are being hot and cold, it's that this is a complicated environment, and I personally want to make a long lasting decision that satisfies all of the facets to the highest degree.

We are trying to decide if we should retire PODC or keep it as an algorithm within Biblepay-core. 
The impetus for removing it is that a lot of us feel that our user-base has stagnated because PODC is too hard to understand and set up.
Thefore, it prevents us from sending the wallet to a brand new user - and allowing them to figure out on their own how to set up mining, receive rewards and tell their friends about BBP (free advertising and growth).

The problem with keeping both algorithms is it requires constant maintenace from the developers to focus on more than one.  The other problem is splitting rewards by 96% and 4% does not give POG the chance to grow.  So, the question is, should we completely retire PODC, and give the budget over to POG, so that POG can potentially grow our userbase automatically?

It could also be potentially floated to split the algorithms 50-50, allowing them to compete.  However, the issue with this is then our IT department still must support PODC and all of its related dependencies and infrastructure.  And, does a 50% PODC environment help biblepay more than a 100% POG environment?

That is what we will be discussing here.

Let me name off some of the facets in a mining algorithm:
IT Development Hours
IT Maintenance Hours
Coolness factor
Risk of a constantly supply of work units
User attrition/augmentation levels, Practicality, User Acceptance, Ease of Use, Community Growth/Price appreciation/Total orphan benefit
Algorithm Extensibility/Fragility
Hard emission reconciliation/Oracles, Whale Approval
Total infrastructure size and maintenance (3rd party credit sites, credit network, debug tool sites, pools)
Greed-Arms Race-Rat Race Levels
Jesus' (Christian Growth) levels/Christian Attraction/Christian Future
Blockchain Security

To start to compare the PODC algorithm to POG, let me first attempt to name some of the pros and cons of PODC:
NOTE!  The following views are *my opinion* as founder; if you disagree please have a civil conversation below, and vote appropriately.

Pros with PODC:

IT/Development: The Creation of PODC is already coded
Coolness:  The Rosetta cancer mining program is 'cool' and gives us a good image as in doing positive work for humanity, the highly technical users are drawn to 'try' podc as a challenge
Extensibility: The algorithm is modular (in that it works outside of biblepay and uses a sanctuary consensus),  and extensible (in that business logic changes can be made at the sanc level without requiring a mandatory)
Price Support: PODC has the 20bbp-per-rac rule meaning it "may or may not" cause price appreciation (I vote neutral on this as we can't tell at this point if this is good or bad for our price, since we appear to be stagnating).

Cons with PODC:

User Acceptance: The algorithm requires a dictionary of terminology to understand, so it appears to be complicated to learn by newbies, it appears to be complicated to be activated and maintained (without knowing the inner workings under the hood to understand how to keep it purring)
Dev Maintenance:  Development hours for Enhancing podc are still not complete, the algorithm certainly needs improved in the area of ease of use, the maintenance hours involved in maintaining PODC from an IT standpoint are relatively high
Fragility:  Fragility is high,  the risk of the contract breaking or changing is high, and the  BOINC/Rosetta/WCG interface risk is high
Work-unit-risk: The risk of work-units running out is medium to high
User attrition levels:  User levels appear to be low and stagnating (based on our sideways to shrinking podc diff level and user count), podc appears to attract richer users with many horizontal computers (in contrast to average users with a low pc count)-and this appears to stagnate growth as the rich users take a high percentage of rewards away from the small users.  The small user base appears to have stagnated our price into a range of 7 satoshi (due to the average miner being reluctant to sell below the electricity cost of PODC).  (I feel BBP has a much bigger potential in many other ways). 
Infrastructure Size and maintenance: The total infrastructure size is High (due to needing 3rd party tools for debugging and for credit reporting), and third party sites like pools and web support sites need maintained.
Greed-Rat-Race-Arms Race Level:  The Greed/Rat-Race level appears to be very high (as each user wants to achieve higher RAC than others) and this appears to create an environment in BBP where higher results are more important than talking about the gospel (Ive posted many snippets to links about Jesus in the middle of our forum, and actually was screamed at by people saying I was spamming, but yet I dont recall anyone starting a real conversation - other than a couple people who just disagreed about the Jews a year ago).
  The people we are attracting to the community for cancer research seem to be more scientific and less Theological (this is entirely an assumption and I dont mean to offend anyone - I actually want the atheists to come, but they dont appear to be coming to learn about Jesus from PODC), and I realize this is a hard requirement, so I simplify this down to : how can we attract a LOT of new users that turn to Christians that stick around.
Blockchain Security:  We have less hashpower being directed at POBH and more to PODC (because financially PODC pays 96% of the reward) so this results in less total network security with more machine power being used for RAC. 
Oracle/Whale Approval:   Whales may be reluctant to jump in as a BiblePay investor if emissions are not fully reconcilable in a hard way on-chain (when the whale takes into account the entire subject for coinbase-reconciliation).

Pros with POG:

IT/Creation: POG is coded,  99% of the POG maintenance (est) is already completed
IT/Maintenance:  POG is low maintenance
Work-Unit-Risk: POG does not have a work-unit limit
User attrition/growth:  POG has the capacity to attract *more users per consumed electricity KWH than PODC* because it is 80% greener than PODC and in addition it rewards users for holding distinct coins (meaning that a reconciled POG user daily reward points to One head, not many machines) therefore I conclude POG equals more HEADCOUNT than PODC, This theoretically means BiblePay expands its participation level, this results in community growth/help with tasks/price appreciation/more orphans, POG is very easy to setup - it is almost turnkey.
Fragility:  The algorithm is not fragile
Reconciliation/Trust/WhaleApproval: The payment emissions are hard and reconcilable, there is no oracle / trust issue, there is no tampering issue, POG would theoretically be whale approved.
Infrastructure: POG reduces total infrastructure down to an in-wallet novel pool and removes the need for 3rd party credit sites, pools, and debug tools.
Greed-arms-race-rat-race:  The rat-race and greed level appears to be very low (as people will be Giving to the foundation to receive a reward and hashing on single machines per head) and only out of personal generosity running multiple hashing machines.   
Christian Growth:  The total headcount appears to be aligned with increasing the attraction of Christian community members
Blockchain Security:  Security is increased due to having an increasing reward (1 mil per day towards pog) means a 10* userbase size increase, meaning a 10* POW security increase.  POG scales well to thousands of users.

Cons with POG:

Coolness factor: POG is much more "simple" than PODC (IE we aren't solving humanity's most complex problems) so we lose the "cool" factor of cancer-mining.
Extensibility:  POG can't allow us (currently) to change its rules without a mandatory (extensibility). 

Archived Proposals / Cameroon One - Installment 2
« on: February 23, 2019, 05:58:03 PM »
We only rose $492.55 last month due to our low price, so we are asking for 2 mil more for Todd at Cameroon One.

Note: Todds colleague Hillary will handle the liquidation, thanks Hillary!

Archived Proposals / Compassion Feb 2019 recurring orphan sponsorships
« on: February 20, 2019, 12:27:59 PM »
To maintain our 102 orphan sponsorships:

Capping at 6 mil.

Archived Proposals / Feb Payroll
« on: February 20, 2019, 12:22:09 PM »
Commits on Oct 26, 2018
Merge pull request #48 from thesnat21/Update_Default_Theme 

biblepay committed on Oct 26, 2018
Commits on Oct 17, 2018 

biblepay committed on Oct 17, 2018
Commits on Oct 16, 2018 

biblepay committed on Oct 16, 2018
Commits on Oct 7, 2018 Upgrade 

biblepay committed on Oct 7, 2018
Commits on Oct 6, 2018 Upgrade 

biblepay committed on Oct 6, 2018
Commits on Oct 3, 2018 

biblepay committed on Oct 3, 2018
Commits on Oct 2, 2018 

biblepay committed on Oct 2, 2018
Commits on Oct 1, 2018 Upgrade 

biblepay committed on Oct 1, 2018 Upgrade (at block 77000) 

biblepay committed on Oct 1, 2018

Commits on Oct 30, 2018 Upgrade 

biblepay committed on Oct 30, 2018 - Leisure 

biblepay committed on Oct 30, 2018
Commits on Oct 26, 2018
Merge pull request #47 from thesnat21/Add_exec_helper 

biblepay committed on Oct 26, 2018


120 hours for the month of October:
 23,076,923 bbp

Capping at 3.5 Million

Archived Proposals / Re-Enable Team BiblePay Requirement in PODC
« on: January 19, 2019, 04:25:52 PM »
I recommend that we hold an emergency vote that Proposes that Team BiblePay be REQUIRED to participate in PODC  rewards (in contrast to having no team requirement).

The reason for this is TheSnat has discovered that 5 Gridcoin users are sharing UTXOs by sending them back and forth to each other more than once per day.

Although we have a feature to Stop this behavior, the spork is not fully enabled in prod because it would require a mandatory upgrade (to ensure all of the remaining sancs honor this setting).

In the mean time I feel it is highly unfair to leave this activity unchecked at the expense of our core team.  (The activity is penalizing small users rewards at the expense of the bad actors).  (We estimate the ill-achieved UTXOs to be rewarding 20% of the PODC budget per day.)

Therefore I recommend that we vote in the Team Requirement to be REQUIRED again within 48 hours.

Secondly, we have been very patient, and the original idea behind Not requiring the team was that BiblePay would grow in popularity by reaching the mass of boinc users.  IMHO, it clearly has not had that effect.  What we have observed is a few very large users (I am told Turkish) have been hogging the top rewards, and we have seen stagnation.  This is actually driving away our smaller users.

Thirdly, our PODC difficulty level has not increased since we removed the team requirement, it has decreased.

In light of this I recommend the sanctuaries consider these factors to vote the way you feel would be best for the community at large.

Vote YES for us to REQUIRE TEAM BIBLEPAY to participate in PODC.

Vote NO for us to leave PODC as is and Not require a particular team.

Archived Proposals / Release POG Mining to Prod
« on: January 19, 2019, 04:10:00 PM »
This proposal authorizes the BiblePay Dev Team to release a mandatory upgrade that includes a change to our primary mining algorithm:

We will switch our primary heat mining algorithm to POG (Proof-of-Giving), which includes our existing POBH (proof of bible hash) heat mining algorithm, but changes the payout mechanism to use an in-wallet pool.

This means that 80% of the Heat Mined Rewards (POW) will go into the POG pool (in contrast to being given to the POW miner who mined the block).
20% of the Heat Mined Rewards (POW) will be given to the Reaper (the one who mined the block).

BiblePay POBH has an inherent 51% attack prevention mechanism called nonce-limiting that helps prevent a 51% attack.  We also have DGW (Dark Gravity Wave).

On a related side-note, in the future, we plan on implementing the 51% attack eliminator (being released in Evolution) which is technically viable since we have Sanctuaries, therefore we embrace the idea.

This proposal does not eliminate the PODC (proof-of-distributed-computing) budget - we will enter a separate proposal for that.

In approximately 30 days our mandatory release will enable us to go live with POG.  This proposal authorizes POG daily pool payments to go live with the characteristics outlined above.

Archived Proposals / Compassion Jan 2019 Recurring Orphanage Sponsorships
« on: January 19, 2019, 01:14:35 PM »
We currently sponsor 102 children at Compassion with a recurring charge of $3,876 per month.  (Approx 9.4MM BBP monthly).

I am requesting 4 million this month (to allow our other due Charity proposals to fit).

Archived Proposals / Cameroon One 2019 Quarter 1
« on: January 19, 2019, 12:51:34 PM »
It's time to renew our relationship with Cameroon One for the year 2019!

We currently sponsor 10 orphans through Cameroon One:

Our budget ran out on the last day of 2018.

I've had initial talks with Todd from Cameroon, and I must say I am extremely excited about continuing our relationship and expanding it.

I mentioned to Todd that we had a little bit of unhappiness with his competitor (our primary orphan partnership) - the organization's lack of motivation in certain areas.  Without being negative, we have met resistance when we asked if we could start an ad campaign and use the partner's logo and boilerplate message next to our primary campaign logo, also met resistance when seeking IT relationships for the creation of Orphan Mining, met resistance when asked if we could have more than one auditing report, and met resistance when asking if we could have assistance in Biblepay liquidation (to fiat).  This led me to ask Todd if Cameroon would be more flexible, and to my great pleasure, Todd has gone the extra mile for us, and promised to extend our relationship by accommodating us in many more ways (for example, working with us on IT projects, and liquidating BiblePay!).

In light of this I believe the least we can do is extend our current relationship through 2019 and not impact our Cameroon in any way.  We may even consider expanding our relationship with Cameroon, if our budget permits, at the expense of our other orphanages who do not feel like working with us.

Therefore, I am requesting that we pay Cameroon in 4 quarterly installments.  We must raise $4,000 per year, equaling $1000 per installment.

For installment one, I am requesting $1000 or 2,439,024 BBP at current rates.

Thank you!

EDIT: ! NOTE !   We are going to send the winning proposal funds directly to Todd for liquidation!  I am excited about this, as Todd as stepped up and agreed to help us decentralize BiblePay.

Archived Proposals / Jan 2019 IT Expenses and Payroll
« on: January 19, 2019, 12:33:54 PM »
I worked approx 120 hours in October for BiblePay on Core maintenance, Core new development, core support, and Pool support (as related to Orphan support and SQL administration).

$120 * $40hr = $4800 = 11.7MM BBP;  Capping at 3 Mil to allow other parts of the IT budget to be paid.

Commits on Oct 30, 2018 Upgrade 

biblepay committed on Oct 30, 2018 - Leisure 

biblepay committed on Oct 30, 2018

biblepay committed on Oct 26, 2018

biblepay committed on Oct 26, 2018
biblepay committed on Oct 17, 2018

biblepay committed on Oct 16, 2018

Commits on Oct 14, 2018
Updating default theme in loadStyleSheet function

biblepay committed on Oct 7, 2018
Commits on Oct 6, 2018 Upgrade 

biblepay committed on Oct 6, 2018
Commits on Oct 3, 2018 

biblepay committed on Oct 3, 2018
Commits on Oct 2, 2018 

biblepay committed on Oct 2, 2018
Commits on Oct 1, 2018 Upgrade 

biblepay committed on Oct 1, 2018 Upgrade (at block 77000) 

biblepay committed on Oct 1, 2018

Archived Proposals / Pool letter writing refill
« on: December 25, 2018, 11:21:56 AM »
Im requesting 250K for letter writing rewards.

The pool has paid out more in rewards and faucet starts than received by proposals (the rest was funded by me).

Archived Proposals / Dec Payroll
« on: December 12, 2018, 11:09:08 AM »
I am requesting some compensation for September 2018 development hours:

Commits on Sep 30, 2018 Upgrade 

biblepay committed on Sep 30
Commits on Sep 27, 2018 Upgrade 

biblepay committed on Sep 27
Commits on Sep 26, 2018 Upgrade (Mandatory for Sancs) 

biblepay committed on Sep 26
Commits on Sep 24, 2018 

biblepay committed on Sep 24
Commits on Sep 22, 2018 Upgrade 

biblepay committed on Sep 22 Upgrade 

biblepay committed on Sep 22 Upgrade (Mandatory for TestNet) 

biblepay committed on Sep 22
Commits on Sep 18, 2018 

biblepay committed on Sep 18 (Mandatory for TestNet) 

biblepay committed on Sep 18
Commits on Sep 17, 2018 

biblepay committed on Sep 17
Commits on Sep 16, 2018 (Mandatory for TestNet) 

biblepay committed on Sep 16
Commits on Sep 15, 2018 

biblepay committed on Sep 15
Merge pull request #43 from sunk818/patch-2 

biblepay committed on Sep 15 Upgrade 

biblepay committed on Sep 15 Upgrade (Mandatory for TestNet) 

biblepay committed on Sep 15
Commits on Sep 14, 2018 Upgrade 

biblepay committed on Sep 14 Upgrade 

biblepay committed on Sep 14

Commits on Sep 13, 2018 Upgrade 

biblepay committed on Sep 13 (Mandatory for TestNet) 

biblepay committed on Sep 13
Commits on Sep 7, 2018 Upgrade (Mandatory for Testnet) 

biblepay committed on Sep 7
Commits on Sep 2, 2018 

biblepay committed on Sep 2 Upgrade (Mandatory for TestNet) 

biblepay committed on Sep 2

I worked on BiblePay approx. 120 hours in September (primarily on creating a Business Object, an RSA keypair, and the ability to send and receive objects from IPFS).

This equals $4800 or 13MM bbp.

Capping at 2 MIL in case we have other dev proposals this month.

Archived Proposals / Compassion Dec 2018 Recurring Sponsorships
« on: December 12, 2018, 10:51:24 AM »
So let us all exercise a small recap with compassion.

After the HODL crash we decreased our child count to 100 (this is approx $3800 per month for 100 children).

We received a credit from compassion for the cancelled 229 memberships (and our revenue and expense records in IPFS and SQL match to the penny regarding the cancellation date and amount in which this credit took effect).

To see the state of our compassion credit balance as of 10-20-2018:

We had a credit of -$25,404.00 at that time.  I've been monitoring the situation to see how quickly we have been burning through the credit and approx at what date we will need to cancel more children.

Based on my projection we are down to -17804 as of this month (anticipating our normal monthly charge hitting around the 20th) meaning that we are down to a 4 month buffer.

I think in the spirit of our normal 6 month buffer we should be looking at canceling 50 more children in approx 60 days, if things dont improve.

As far as this months request, remember, last month we had such a terrible month we only gave $5 to 65% of our children (and requested a tiny 1 mil budget), and in light of that I have no choice to request approx. 6 mil bbp (as to not consume the entire charity budget) but we need to attempt to put a dent in this months amount owed of $3,800.00.

Therefore I request 6 mil this month.

Note that anyone can view the actual expenses and revenue by clicking "Accountability" in the pool.

Archived Proposals / New Exchange Fund - BiblePay
« on: December 12, 2018, 10:26:55 AM »
Now that Jaap has been compensated for finishing CoinExchange.IO I would like to start a new piggy bank for our new exchange fund (Jaap is taking a break until further notice).

We have an offer to be with Cryptopia for 1.5BTC.  If nothing better comes along, this might be our best option - hopefully by December 2019.

I plan on periodically converting the latent BBP balance to BTC so as to not add liquidation risk.

I also plan on keeping records of the balance and conversion activity in our SQL server so we can see how far along we are as we go.

I am requesting 1 mil to start.

TestNet Discussion Archive / Testnet - Test Proof of Giving
« on: December 06, 2018, 01:00:46 PM »
Welcome to the dedicated testing thread for Proof-of-Giving II (POG).

POG is a mining algorithm based on POW, POBH, Tithing to the foundation, an integrated mining pool, and some elements of POS.

Please see the following technical description:

And the summary for beginners:

In summary, POG is integrated in the wallet, it is a mixed mining pool with 20% of the reward to the miner/80% reward split between the integrated pool recipients.  The pool participants are based on those who tithed to the foundation (helping our monthly orphan sponsorships) in the last 24 hours.  The tithe_weight for each user drives the pool block reward.

The Proof-of-giving difficulty level will be available in the wallet.
It will display:
min_coin_age:  This is the minimum age in days a coin is eligibile for tithing.
min_coin_amount: This is the minimum coin amount eligibile for tithing.
max_tithe_amount:  This is the maximum allowed tithe amount.

If you meet the conditions you may tithe and become part of the mining pool.
All of the "sowers" (those who tithed) will be rewarded 12 times per day (once every 16 blocks).
After paying the "reaper" (the block solving miner) 20% of the block reward, the remaining 80% will be split among the sowers.

The POG pool is always 205 blocks wide (24 hours), meaning the tithe_weight's in the pool span from the current block back 205 blocks before the current block.

As an example, if sower A tithed at 11 AM yesterday, and sower B tithed at 10 AM today, and the current time is 10:30AM, these two sowers are in the pool.  However, a user who tithed 26 hours ago is NOT in todays pool.

As each block passes, the pool will pay 1/16th of the recipients based on the individual sowers Tier.  Each tithe is inducted into a tier based on the block # it was Tithed in (not according to its amount). 

So what you can expect as far as rewards:  You will receive 12 rewards per day if you have active tithes in the pool.  Once the tithe expires, you no longer have tithe_weight.


The wallet is set up to automatically tithe for you once every 4 hours.  The wallet will scan your available coins sorted by age and amount, and use the most applicable SINGLE COIN for a tithe automatically.  It will automatically send the Maximum amount possible.


Method 1 - QT: To tithe manually, go to the QT send money page, and click Donate to foundation.  At this point the POG difficulty parameters will appear on the screen.  Select the appropriate tithe amount and click send.  If the coins are not old enough or high enough in value, an error will appear.

Method 2 - RPC:  From the RPC console, type 'exec tithe amount'.
If the tithe fails, a reason will be given.


To see the difficulty parameters, type 'getmininginfo'.


Type 'showblock blocknumber'. 
See 24_hour_tithes, pog_difficulty, min_coin_age, min_coin_amt, max_tithe_amount.
The historical 24_hour_tithes will show the amount tithed in the last 24 hours.
The block_tithes will show how many legal tithes were inducted from that block.


Type 'exec pogpool'
This report will show the actual live POG POOL and everything in it.
In this pool, we have 16 payment tiers containing an even distribution of sowers (based on each individuals tithe_height).
This will show us the count and sum of tithes per tier. 
Note that if a sower's nickname is available, it will be listed here in place of the address.
(In the near future, we will summarize this list in a nicer way, this is basically a verbose list for debugging purposes).
You can also see the tithe totals, and at the bottom, the sum of your own personal tithes.

In your biblepay.conf file set the key 'nickname=my_nickname' and restart the wallet.

Upgrade to  Start with '-testnet=1' flag.


exec tithe tithe_amount min_coin_age min_coin_amount:
This command searches the wallet for coins older than min_coin_age and of greater value than min_coin_amount and tithes that single coin in an amount of "tithe_amount". 

exec getdimensionalbalance min_coin_age min_coin_amount
This command scans the local wallet for coins older than min_coin_age and min_coin_amount, and creates a report based on age and value.  You can use this command for debug purposes in testnet to find coins that may be applicable for manual tithing.  (And for debugging current tithe levels).

exec pogpool:
Use this command to see the current payment tiers (0-15).
You will see the user nickname, public receive address, tithe amount, tier, tithe_height.

Then you will see the total tithes per tier.
Then finally you will see the Highest tithe and the amount of personal tithes you have contributed.

exec bankroll quantity denomination:
This command allows you to generate 'quantity' of tithing BBP notes of 'denomination'.  Then you can let them age, and use them for tithing later.
Example: exec bankroll 50 5000, this command will spend 250,000 bbp (back to yourself), and you will receive 50 quantity of 5000 bbp notes.  At this point they will age, and they can be used for tithing.  Note:  We mark the bank notes with a 1millibbp suffix so that we can modify podc_update to skip spending these in the future.


1.  Verify that once a tithe is sent to the foundation, it can be seen in a historical block.  You may do this by sending a tithe, waiting for a confirm, then typing:  exec showblock blocknumber.  The fields near the bottom labeled pog_ will show if the tithe has been included in the block.

2.  Verify that sending more than one tithe in one 24 hour period results in increased tithe_weight for you.  And increased total tithes in the pool.

3.  Verify the integrity of the pool.  Audit the pool and reconcile the pool.

4.  Verify the difficulty level parameters per block and per 24 hour period.  Ensure difficulty algorithm is oscillating perfectly and properly according to the tithe history.

5.  Scan debug.log for any trace of "POG Recipients Invalid".  This error should not be in the log.

Archived Proposals / Mass Adoption for BiblePay II
« on: November 29, 2018, 06:02:22 PM »
When voting please consider a non-technical investor who wants to mine- remember to consider a person that has a busy lifestyle that does not want to follow more than 1-2 steps before losing patience, and has no interest in learning any new acronyms.

With PODC - we would need to pull in developer resources to shield the user from acryonyms, and find a way to concentrate new user mining power to a boinc project with fair payment without exposing the user to technical terms and requiring them to monitor RAC on disparate sites.  We also have quite a bit of infrastructure to support PODC: supporter pools, diagnostic tools, help desk answers, forum posts, etc.  Consider the total barrier of entry and ongoing maintenance per user and for the codebase.  Also consider the risks if BOINC changes the code, the interface, breaks or gets hacked.

With POG II - we would move back to our Proof-of-bible-hash style mining, on generally one machine per user (IE tither).  People would be rewarded with mining rewards in a "pool" depending on how much they tithe to the orphan foundation per day.  This solution would be more of a one-click setup, with the only decision needed by the end user to either manually tithe or set up an automatic tithe.  The maintenance should technically be lower for both user questions and the IT codebase.  There is not a chance of third party site being hacked or an oracle requirement.  The 51% risk appears to be low (the same as PODC or lower, as long as sleep capability is well designed).  One potentially large side benefit:  Being possibly the first crypto with an integrated pool - and not requiring third party pools.
(Rob recently added a proof-of-giving difficulty algorithm to address the top 2 POG problems:  Monthly tithe cap to prevent a massive monthly dump, and preventing a hacker from using a tithe script attack).  With these two improvements, voting is being re-evaluated.
Please read this wiki:
And this wiki:

With POOM - we decentralize our orphan sponsorships out to the individual miners.  The miners are rewarded with an amount of biblepay that is carved out of the heat mining budget in relationship to their monthly private commitment amount.  The downside to POOM is this requires a centralized API at, and biblepay has the ability to log in and audit individual user compassion accounts.  The plus is its very green, and diverts electric costs over to orphan sponsorships.

With IPFS - we require each user to make firewall rule changes, run a flavor of an IPFS server, allocate a portion of the hard drive, and we have the sanctuaries grade each miner on file hosting quality.  The downside to this is:  IPFS is still volatile, sometimes crashing on the pool server, the interface may change, the setup for a miner would be complicated, and we have no documentation for this complete yet, and we haven't finished the proof of concept.  The positive side is its futuristic.

Pages: 1 2 3 [4] 5 6 7 8