Topics

151

Archived Proposals / February 2018 IT Expenses (Payroll)

« on: March 16, 2018, 05:29:50 PM »

To partially fund some of my own programming hours, I would like to submit Github commits for the core biblepay wallet from Nov 1 2017 through Nov 30 2017:

Commits on Nov 29, 2017
1.0.6.3-Mandatory Upgrade - TESTNET  …

@biblepay
biblepay committed on Nov 29, 2017
 
Commits on Nov 20, 2017
1.0.6.2-Leisure  …

@biblepay
biblepay committed on Nov 20, 2017
 
Commits on Nov 17, 2017
1.0.6.1b-Leisure (Highly Recommended Upgrade)  …

@biblepay
biblepay committed on Nov 17, 2017
 
1.0.6.1-TESTNET  …

@biblepay
biblepay committed on Nov 17, 2017
 
Commits on Nov 16, 2017
1.0.6.0-Testnet-Leisure  …

@biblepay
biblepay committed on Nov 16, 2017
 
Commits on Nov 15, 2017
1.0.5.9b-Leisure  …

@biblepay
biblepay committed on Nov 15, 2017
 
1.0.5.9-Leisure-Testnet  …

@biblepay
biblepay committed on Nov 15, 2017
 
Commits on Nov 13, 2017
1.0.5.8c-Testnet  …

@biblepay
biblepay committed on Nov 13, 2017
 
1.0.5.8b-TestNet  …

@biblepay
biblepay committed on Nov 13, 2017
 
Commits on Nov 12, 2017
1.0.5.8-Testnet-Leisure  …

@biblepay
biblepay committed on Nov 12, 2017
 
1.0.5.7-Leisure  …

@biblepay
biblepay committed on Nov 12, 2017
 
1.0.5.6b-TESTNET  …

@biblepay
biblepay committed on Nov 12, 2017
 
Commits on Nov 11, 2017
1.0.5.6-TESTNET-Leisure Upgrade  …

@biblepay
biblepay committed on Nov 11, 2017
 
Commits on Nov 9, 2017
1.0.5.4b (TESTNET) - Leisure Upgrade  …

@biblepay
biblepay committed on Nov 9, 2017
 


For a grand total programming time of (40 hrs per week * 4 weeks) = 160 hours @ 40.00 per hour = $6,400.00

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

Zinc, Exchange, SSL for wiki.biblepay.org, and resource upgrade for biblepay.org for Wordpress ($313.08):
Receipts:
http://pool.biblepay.org/SAN/expenses/ITExpensesBiblePayFeb2018.pdf


For a Grand Total Proposal of :  $6,713.08
Equaling:

?6713/.002930 = 2,291,126 BBP


Thank you for your consideration.

152

Archived Proposals / Staking Amount Required Per Magnitude for Proof-Of-Distributed-Computing Mining

« on: March 09, 2018, 12:19:06 PM »

All,

Our PODC Distributed Computing superblocks pay based on a researchers magnitude, which is assessed once per day by the Sanctuary Quorum.

The magnitude ranges between 0 and 1000 per CPID (that is per researcher).

The proposal is geared towards requiring Super Users to Stake More Biblepay in order to be compensated for research.

With the thought that a mining organization, a previous bot-net, who deploys 500 machines yet only stakes 50,000 BBP will be receiving massive rewards and diluting the earnings of the small users who are less fortunate to afford that kind of big mining equipment.

In the spirit of increasing competition, we propose to require approx. 2500 BBP per magnitude, meaning that if you are a researcher with 4 computers, let us assume your magnitude is 20, then you would be required to set your utxoamount=50,000 in order to receive full research compensation.   If you only stake 25,000 on a given day, in this case your reward compensation would be multiplied * .50.

For another example, let us take a power user with 255 machines, and a magnitude of 300.  Since this user virtually controls a third of biblepay's emission level, if the 2,500 BBP UTXO requirement were in place, that CPID would need to stake 750,000 BBP per day to maintain the full reward level.

Thank you for your participation.

153

Archived Proposals / Proposal: Proof-Of-Distributed Computing as major reward algorithm

« on: February 10, 2018, 11:38:12 AM »

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:
http://wiki.biblepay.org/Distributed_Computing


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.

Security:

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.

154

TestNet Discussion Archive / BIBLEPAY -TESTNET TESTING THREAD-Proof-Of-Distributed-Computing(Cancer Research)

« on: February 06, 2018, 04:00:36 PM »

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 :  https://github.com/biblepay/biblepay
Version: 1.0.8.8k - Leisure

NOTE:

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:
http://wiki.biblepay.org/Distributed_Computing

See guide:

How to Get Started with Distributed-Computing:
http://wiki.biblepay.org/Distributed_Computing_Start_Guide


**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.

155

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
1.0.5.4-Leisure (TESTNET)  …

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

@biblepay
biblepay committed on Oct 30, 2017
3d78c93 
Commits on Oct 29, 2017
1.0.5.2-Leisure (TESTNET)  …

@biblepay
biblepay committed on Oct 29, 2017
afbcfe4 
Commits on Oct 28, 2017
1.0.5.1-Non-Mandatory  …

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

@biblepay
biblepay committed on Oct 28, 2017
392d272 
Commits on Oct 27, 2017
1.0.4.9-Non-Mandatory (TESTNET)  …

@biblepay
biblepay committed on Oct 27, 2017
14230b6 
Commits on Oct 6, 2017
1.0.4.8-Non-Mandatory  …

@biblepay
biblepay committed on Oct 6, 2017
9a82919 
Commits on Oct 3, 2017
1.0.4.7b-Non-Mandatory  …

@biblepay
biblepay committed on Oct 3, 2017
e77652e 
Commits on Oct 2, 2017
1.0.4.7-Non-Mandatory  …

@biblepay
biblepay committed on Oct 2, 2017
98e8f9b 
Commits on Oct 1, 2017
1.0.4.6-Non-Mandatory  …

@biblepay
biblepay committed on Oct 1, 2017
9a1575b 


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
http://pool.biblepay.org/SAN/Expenses/ZincJan2018.pdf

Cloudflare charges = $20.00
http://pool.biblepay.org/SAN/Expenses/ZincJan2018.pdf

For a Grand Total Proposal of :  $3720.00
Equaling:

?3720/.003765 = 988047 BBP


Thank you for your consideration.

156

Archived Proposals / February 2018 Compassion.com 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 Accountability.biblepay.org | 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 accountability.biblepay.org | 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 compassion.com and Rob will 'tip' in a little extra to ensure Gods money is put to use for Gods children.

157

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:

https://activara.net/yobit/


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

158

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:

http://wiki.biblepay.org/Proof_Of_Loyalty


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.

159

Archived Proposals / Faucet Refill

« on: December 26, 2017, 09:17:50 AM »

The pool at pool.biblepay.org 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.

160

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 (http://www.biblepay.org):
$140.58
http://pool.biblepay.org/SAN/Expenses/WebHostBiblepay2017.png

Next, the linux web hosting fee for one year for the wiki site (http://wiki.biblepay.org):
$63.83
http://pool.biblepay.org/SAN/Expenses/WebHostWiki2017.png


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:
$200.00

http://pool.biblepay.org/SAN/Expenses/ZincOct2017.pdf
http://pool.biblepay.org/SAN/Expenses/ZincNov2017.pdf


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:
https://github.com/biblepay/biblepay
https://github.com/biblepay/biblepay/commits/master?after=db75cc7a1cfde21cf694dc882f731783f28a0ae7+34

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

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

161

Archived Proposals / December 2017 Compassion Expense Reimbursement (Monthly Orphan Premiums)

« on: December 20, 2017, 06:05:26 PM »

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 Accountability.biblepay.org | 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 accountability.biblepay.org | 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:
http://pool.biblepay.org/SAN/Expenses/CompassionDec2017.pdf

Summary:

$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.

162

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?

Thanks.

Budget Source: PR Budget

Amount: 1000 BBP


I think this move will be good for PR.

163

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.

164

TestNet Discussion Archive / Biblepay Superblock Final Allocation Breakdown Modification Poll

« on: November 03, 2017, 11:37:28 AM »

All,

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!

165

TestNet Discussion Archive / BIBLEPAY - TESTNET THREAD - TESTING SANCTUARIES FOR GO LIVE AT CHRISTMAS

« on: October 03, 2017, 01:07:26 PM »

Good Afternoon All,

It is time to Test sanctuaries in Testnet.

- Testing requires linux - because windows will not run watchman on the wall (thats the decentralized sanctuary database)
- Testing requires 500,000 TestNet BBP to be sent to the new testnet masternode (actually send more, so you have extra first) - this is not the final amount to run a sanctuary, its the testnet amount
- Testing requires an external open IP, IE you need to be able to run with the firewall port 40001 open
- Testing needs to have the latest version of BBP compiled from source

If anyone needs test BBP, let me know.

Here is a guide to explain how to start a masternode:

http://wiki.biblepay.org/Create_Masternode
(*** NOTE!!!  The above guide says 1 million BBP is required.  Its actually 500,000 BBP in testnet!  Please dont try 1 million as it will not work ***)





** Note that this procedure documented above actually failed.  It failed when I took a look at the log in the actual masternode wallet, an error was generated saying something to the effect of invalid escrow sent to the masternode. 

To get around this, send the test biblepay to the masternode wallet, create the  private key on the masternode, set the masternodeprivatekey and masternode=1 in the config, and then we can resume testing.  If anyone can get this working in 'cold' mode (that means the mastnode has 0 funds in the wallet with remote activation working) that would be extremely valuable.  I will obviously help with this, as we cant go live until cold mode works, but I also need to move past and start testing the governance commands next.

My first test procedure is lets ensure we have 5+ masternodes running and see if we can all see each other and stay in sync.  We now have 1 minute blocks on testnet.

PS: To install watchman-on-the-wall, please see the "BuildBiblePay.txt" document in the root.  It has a section called Watchman. 

Note, I will modify the wiki entry to explain how to add watchman to the cron.