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
The primary purpose of this proposal is for the approval for us as a community to use Proof-of-Distributed Computing as a major reward algorithm in biblepay, and as a tool to help bust the botnet.

Please read some of the background info on PODC here:

Block Security

With Proof-of-distributed-computing enabled, I propose that we continue to use the existing consensus algorithm, PoBH (proof-of-bible-hash),  for block security.

This is so our chains integrity can be maintained, and will not be completely trusted to any 3rd party.  We continue to use DGW (Dark Gravity Wave ) for our difficulty algorithm, this helps us stay less prone to 51% attacks (attacks formed by buying out a percent of biblepay on the market).
    The existing POBH-POW algorithm for chain security ensures that we have a structurally sound blockchain that syncs from zero consistently, and that it is easy for the core wallet to detect forks. 
( This is a major concern, and must be taken seriously).

(This is in contrast a common problem with proof-of-stake consensus systems- where hackers have an attack vector potential created by solving blocks on multiple chains, making it hard for the core wallet to recognize which chain has the most work). In POW based chains, it is easy for the core wallet to stay on track, as the chain with the most work is usually a magnitude more than other chains.

I recommend that we keep the existing POBH-POW-heat mining system for block security, and for chain sync consistency. However, we reduce the payments on the POW-Heat side by 90%, so that we starve off the botnet first of all, by raising the PODC rewards up by 90%.

Imo, no botnet is going to choose to Heat Mine for 90% less when they can choose Rosetta mining for 90% more.
(This is proven in practice in all casinos).

I propose that we promote POBH mining only on the controller wallets, since those wallets would perform sending/receiving of biblepay funds, starting/stopping sanctuaries, managing Rosetta CPIDs, CPID association, and also mining on one thread for our block security.

It has been raised as an issue that if we lower rewards on the heat side by 90%, most strong miners will go away thereby leaving our security more vulnerable to an entity with large dormant hashpower, meaning that they will attempt to come in with a quick hash attack, and take over the chain and issue a double spend.

To combat this, I propose that we limit the ability to solve blocks to only Researchers with Active CPIDs in the chain (associated cancer researchers), with existing Magnitude and coins earned in the last superblock, and limit CPIDs from solving only one block per 6 block period.  What this does is ensures that one researcher cannot enable massive hashpower and solve another block in the confirm period duration.  This would require distinct CPIDs to join in-lessening the chances of an attack.  Since the CPIDs must be actively crunching with RAC and magnitude and be in the prior superblock, a horizonal scaling attempt is not possible  (as it will take at least 2 days to ramp up a new CPIDs magnitude and be paid, while the attackers Old cpids will be diminishing in power).  In addition, DGW already adjusts to the current difficulty level, so a brute hashpower attack is very unlikely to win, with our low nonce rule, the attackers difficulty would rise by exponential amounts per solved block, and if any non-hacker CPID solves a block in between (which is highly likely due to the low nonce rule), the attack is not successful.


In this solution, we require Rosetta CPIDs to actually type in their credentials to become associated with Biblepay.  All other biblepay researchers check the burn transaction in the memory pool, to verify the CPID is actually owned by the owner.  So therefore it is not possible to be rewarded research rewards for any CPID not owned by the owner and verified with the burn transaction.  Once the burn is checked, the researchers signature is set in the chain, and we respect future signed CPID messages from this researcher.  Replay attacks are not possible.

The SanctuaryQuorum votes on the daily Magnitude file.  We have a system in place to ensure only the official CPID magnitudes will pass in the vote (as a net 10% have to vote on the correct hashed contract) in order for the contract to be recognized as valid for the daily superblock.

In addition, the research payments are constructed in a way that divides the magnitudes by the superblock available budget, so if a Rosetta error would occur, the payment error would be relative to that superblocks budget, and would not result in a chain block overpayment (IE we never pay more than the total budget per day) and we divide the rewards by the share of each researchers weight per day.

Unlimited Scalability:

The daily superblock reward system was chosen so that biblepay may scale to allow up to 32767 researchers to be paid concurrently per day.  Since there are currently 48,000 Rosetta servers actively crunching, this system could accomodate every Rosetta CPID as a potential biblepay user!  We also do not require the researcher to quit their team, but through our advanced security, they may come onboard as a loyal biblepay user.  This results in great PR for biblepay.

In summary, this is what I am proposing:

Proof-Of-Work rewards drop to approx 600 BBP per block (a reduction of 90%)
Proof-Of-Distributed-Computing rewards increase to approx 5500 BBP per block (an increase of 90%)
One superblock per day airdrops the researcher rewards, allowing up to 32767 research payments per day

Theory to bust the botnet:

Since POW rewards would decrease by 90%, the botnet would quit heat mining and start cancer mining
POW would require a signed CPID to solve a block
POW would require a CPID to be active and have prior payments to solve a block
Biblepay would have a feature, if no CPID is available in 31 minutes to solve a block, we would allow any heat miner to solve the block (so chain never gets frozen, in case of Rosetta being down etc)
These rules would lower the chances of an outside 51% attack to almost zero, when combined with DGW's protection

I recommend POL to be disabled for now (proof-of-loyalty) and that we instead research ways to include an element of POL in each Rosetta work unit to raise the trust and integrity level of Proof-of-distributed-computing to the highest level for the masses. 
^ If POL is trusted as a sole consensus algorithm, then PODC+POL may be a potential global leading candidate in the future.

PODC also will allow us to achieve a great future milestone:  Mining for the unbanked.  Since Rosetta cancer mining supports ARM tablets and ARM cell phones, it is possible for the unbanked through cancer research to earn enough to live on or at least buy groceries in third world countries.  This is more than we currently have, since POBH currently runs on PCs only.

The financial renumeration for this proposal is only 10 BBP, as our budget is mostly consumed.

Please vote for this if you believe this will not only allow us to be a humanitarian force - one facet of our community is doing what Jesus would do : help heal others, but also if you believe we will help remove the influence of the botnet and take our community back.

Please join us in testing Proof-of-Distributed-Computing, a new consensus algorithm for Biblepay.

This algorithm is designed to divert proof-of-work clock-cycles (heat mining) into cancer-mining-clock-cycles through Rosetta@Home, performing useful work.

Testnet release date :  February 6th, 2018  @   15:58:00.

Windows is still compiling.  Will update when ready.
Please compile Linux from source :
Version: - Leisure


Testnet has changed severely.  Please :
rm blocks -r
rm chainstate -r
rm mnc*.dat
rm gov*.dat
rm banlist.dat

Restart client.

To get started with Proof of Distributed Computing:

See Background info on distributed-computing first:

See guide:

How to Get Started with Distributed-Computing:

**NOTE:  So far, the guide shows how to run Rosetta on Windows (as your cancer miner), and your biblepay wallet on linux (compiled from github).

 I am still in the process of documenting how to install Rosetta on linux ** (Its easy, if you are daring, please check the windows instructions in the guide and give it a shot on linux using the apt-get boinc commands )

PS All credit for this project goes to Jesus.

Archived Proposals / Jan 2018 IT Expenses (Payroll)
« on: February 01, 2018, 08:01:44 pm »
To partially fund some of my own programming hours, I would like to submit Github commits for the core biblepay wallet from Oct 1 2017 through Oct 30 2017:

Commits on Oct 30, 2017 (TESTNET) 

biblepay committed on Oct 30, 2017
25e112a - Leisure Upgrade (TESTNET) 

biblepay committed on Oct 30, 2017
Commits on Oct 29, 2017 (TESTNET) 

biblepay committed on Oct 29, 2017
Commits on Oct 28, 2017 

biblepay committed on Oct 28, 2017
de1d1f4 - Non Mandatory (TESTNET) 

biblepay committed on Oct 28, 2017
Commits on Oct 27, 2017 (TESTNET) 

biblepay committed on Oct 27, 2017
Commits on Oct 6, 2017 

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

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

biblepay committed on Oct 2, 2017
Commits on Oct 1, 2017 

biblepay committed on Oct 1, 2017

For a grand total programming time of  90 hours @ 40.00 per hour = $3600.00

Also, I would like to expense the following recurring IT charges for Biblepay:

Zinc (Amazon integration) API charges =  $100.00

Cloudflare charges = $20.00

For a Grand Total Proposal of :  $3720.00

?3720/.003765 = 988047 BBP

Thank you for your consideration.

Archived Proposals / February 2018 Recurring Expenses
« on: February 01, 2018, 07:26:55 pm »
Each month we sponsor approximately 189 orphans currently.
Rob, the lead dev charges the expense on his credit card, and keeps a copy of the receipt. 
The expenses can be viewed by navigate to | Expenses and viewing the December PDF.

We currently have a surplus of approx. $400 in Robs bank account that he will spend on the Orphan Prepaid Premiums this month (to start our initiative into Prepaying Premiums into the future, at least 6 months in the future to give these children some level of stability).

 See | Orphans | Orphan Fundraisers.  You can audit the total by finding the sum of all fundraisers.

 I am requesting 2894609 biblepay for the February 2018 montly premiums, and anything left over will be used for sponsoring orphan premiums into the future.  There will be a column updated in the Orphan Expenses to clearly show how much progress we made on prepaying after the third week of February (that is when the bill is due each month).

I am committed to spending 100% of this proposals funded amount back into Charitable benefits for the orphans.

All orphanage coins are spent on orphan expenses at and Rob will 'tip' in a little extra to ensure Gods money is put to use for Gods children.

Archived Proposals / New Exchange Proposal - Add new Biblepay Exchange
« on: January 25, 2018, 06:46:01 pm »
Zthomasz, Tom, has spearheaded the initiative to get us listed on a new exchange, possibly Yobit, SouthXchange, or NEXT, or one of the top 50 bitcoin exchanges.

Yobit has a policy where they will list a new coin for .10BTC within 7 days - but we have since discovered they are NOT honoring this agreement.

Tom has started a campaign that accepts USD funds for a new exchange here:
New Exchange Fee Fund Link:

Please post here if you would like to donate in BBP, post the amount so we can keep track of how much we raised.

Archived Proposals / PROPOSAL : Proof-Of-Loyalty
« on: January 20, 2018, 11:43:01 am »
All, recently what appears to be either a harmless mining organization with a lot of nodes, or a botnet has taken over the majority of the hashpower of our network. 

In an attempt to stave off the botnet, I propose an extension to our hash algorithm called proof-of-loyalty.

It makes our PoBH algorithm a hybrid, as the blocks become easier to solve as you accrue more coin-age.

Please see this wiki page for the background information and most technical information:

This feature also helps us straighten the path to eventually mine on mobile devices, as this miner will eventually solo mine a block with enough coin-age without much hashing.

I personally believe rewarding investors and our loyal community members with more rewards and the propensity to solve a block by those in the light will prove to be a positive addition to biblepay, and will allow us (to have) more control during the software upgrade process.

Although this feature has taken more than 40 hours to code in the core client, I am asking for a flat 100,000 BBP reward for this to be voted and merged in to the core client.

All, it's time to test a new Biblepay   8)    Feature!

One that helps us make inroads into third world countries, helps us mine on mobile phones, and helps reward our loyal investors who Tithe!

And most importantly helps foil pesky BotNets.

Please see this wiki page for the background information and most technical information:

Note, that in the biblepay client, the default staking target percentage is set to .10.  (IE 10% of your coins).  If you would like to change it please modify the "polpercentage" key with a whole number between 00 and 100.

For linux:  Please build

or for Windows: Please download v1.0.8.3 from here:
before proceeding.

You may start your client in testnet by adding the "-testnet" suffix.

Let me know when synced and we will start testing.

NOTE:  The linux version currently has no way to notify you that it was a proof-of-loyalty block, I am working on that now.  The QT version does display it.

NOTE II:  This first version does not make any effort to unlock your wallet.  Staking requires an unlocked wallet.  We can discuss this in the thread.  For now, please unlock your wallet for thousands of minutes to test this version (if it is locked).

EDIT III:  If you need an addnode:, we are on block number 514

** Please start with an empty chain in testnet, rules have changed in testnet since last tests **

Archived Proposals / Faucet Refill
« on: December 26, 2017, 09:17:50 am »
The pool at has given out 159,000 BBP.

This is a proposal to reimburse the pool for 125,000 bbp to keep it funded so we can re-enable the faucet for more rewards for new users.

I would like to charge this to the P2P budget.

Archived Proposals / December 2017 IT expenses (payroll)
« on: December 20, 2017, 06:51:41 pm »
For the month of December I am attempting to recover IT expenses for web hosting, AWS integration, our wikipedia and some payroll.

The linux web hosting fee for one year for the non-wiki site (

Next, the linux web hosting fee for one year for the wiki site (

Next, the Zinc integration fee for October and November 2017 (did not receive the bill for December 2017 yet) - this allows us to integrate with the amazon storefront for in wallet purchases:

Next I am only asking for 120 hours of payroll for doing the initial git push for biblepay at $40.00 per hour totaling $4800.00:

(This is for programming time based on the commits checked in for the month of September 2017). 

TOTAL:  $5204  from the IT budget
867,333 BBP (@ .0006 per bbp)

Each month we sponsor approximately 188 orphans currently.
Rob, the lead dev charges the expense on his credit card, and keeps a copy of the receipt. 
The expenses can be viewed by navigate to | Expenses and viewing the December PDF.

Since inception, Rob has spent $30,161.00 for BiblePay orphan premiums.  This can be audited by viewing the sum of all payments using the above link.

Rob has only raised $19,671 in orphan fundraisers however.  See | Orphans | Orphan Fundraisers.  You can audit the total by finding the sum of all fundraisers.

This leaves a deficit of $10,490 owed to Rob for previous activity.
This $10,490 includes our current actual December 2017 invoice for $7,068.00, spent on 12-20-2017.

Receipt here:


$19671 raised
$30161 spent
Out of the $30161, $7068 was for December 2017.

Therefore I am requesting 2894609 biblepay for December 2017 for reimbursement of these monthly premiums.

A new record will be logged as I sell the 2.8MM on the exchange, and anything over will be used to sponsor new orphan premiums (but based on 12 months for stability), so this proposal does not benefit Rob in any way shape or form.

I am committed to spending 100% of this proposals funded amount back into Charitable benefits for the orphans.

Archived Proposals / Unquestionably Horrible Proposal
« on: December 19, 2017, 06:31:57 am »
I have the dumbest idea ever, but would like to receive 1000 BBP for it.

Lets branch BiblePay into a version for non-believers and launch it on April Fools day 2018?


Budget Source: PR Budget

Amount: 1000 BBP

I think this move will be good for PR.

Archived Proposals / First Prod Test Proposal
« on: December 15, 2017, 01:43:35 pm »
This is a test proposal. 

Im asking 250 BBP for fixing an SQL query deadlock in the pool.

EDIT: Please charge this 250 BBP to IT.

General Support / Help with Mining Set Up
« on: December 02, 2017, 07:12:57 am »
If anyone is having trouble setting up the config file for pool mining, please create a topic or post a message here.

Two of the top 6 exchanges have agreed to list BiblePay for a total fee of 3.3BTC in order to help us achieve our goal of sponsoring more orphans.

Should we mint a block for this fee during our mandatory release at Christmas?

Or, should we wait until sanctuaries are up and running and consider making this a budget item in our future PR budget and vote on this like a normal item next year?

(The risk is-- maybe BTC will be more expensive by then, or the Exchange May withdraw the offer).

So, this is one opportunity that looks like we may want to jump on, but I leave this up to the community.


Around Christmastime, we will be going live with Sanctuaries.  At that time, the automatic 10% tithing block (for our Orphans) stops, BUT, with our superblocks and sanctuaries, we will continue to vote to fund the budget to pay for the orphans. 

The current breakdown for each Biblepay block is as follows: (With each block paying between 5000 and 20000 BBP, depending on network Difficulty and the deflation level):

5% is allocated from each block for IT expenses (such as payroll, web hosting fees, partner integration expenses etc).
10% is allocated from each block for Charity (this is where the budget will come from to pay for Compassion for example).

We currently do not have a budget for PR (public relations campaigns) or for P2P features (Features such as orphan letter writing, Pay To Preach, Pay to be a Priest, FAQ writers, Social Media functions, etc).

Since I personally do not wish to change the allocation breakdown now for integrity reasons, I will not make any adjustments at this point to the permanent breakdown. 

     However, with all of the recent good ideas that have been floating around, such as rewarding members for being Discipleship Leaders, or Pay for Priesting, or Pay for Orphan writing fees, etc, and with the positive impact of PR campaigns, I do not wish for us to miss the opportunity to vote  for the possible inclusion of PR budgets or P2P budgets permanently in our superblock reward ecosystem.

Hence the reason we are brought here for the poll.

The poll runs for 31 days (Ending 12-4-2017).

Please vote on potentially changing the superblock budget to include PR and/or P2P expenses on a regular basis.

 If the community decides to include a PR budget or a P2P budget, we will make the necessary adjustments in the Christmas Sanctuary mandatory release, and they will become a permanent part of BIblePay.

Thank you for participating!

Pages: 1 2 3 4 5 [6] 7