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
1
Production Proposals / BiblePay Evolution 2.0 Changes for Future Growth
« on: October 19, 2019, 01:04:03 pm »
BiblePay DSS (Decision Support System) from the CMC (Cryptocurrency economic simulation) model


In the spirit of making solid future changes for BiblePay based on strong mathematical decisions, I have written a program called the 'CryptoCurrency Economic Simulation'.

In this CES, we attempt to create a synthetic model that reverse engineers DASH's success.  In the model, we have the money supply, the emissions per day, the GetBlockSubsidy rules, the dash 7.1% deflation level, and many assumptions based on new users per day, theoretical miner count, the buying activity by miners, the buying activity by investors, the investor count, the miner liquidations per day and expenses, the governance expenditure percent, the % allocated to charity (IE the % of payroll vs charity), assumptions on whale liquidations vs price, the market cap from CMC per day, etc.

The goal is to allow the program to run and see if the model will match the actual price in history then let it create the effect(s) into the future, and therefore then allow us to plug in theoretical changes to the dash model for BiblePay, and resimulate then decide what elements of our infrastructure should be changed that will improve the future.

For Dash, the basic premise is they cap the governance emissions level per month at 10%, they have a 7.1% annual deflation level, DGW limits the payout per block when difficulty rises, and since the Masternodes lock half of the money supply up, that causes less money supply to be available, theoretically increasing the price.  A very influencing factor to growth is the amount of new users per day (augmentation and negative attrition levels).  For dash, they attract about 50,000+ miners to the coin due to the price per block payout per month.  With an electric cost of $20 per month, you can imagine that the DASH infrastructure can support this many people.  All of these people contribute to a positive impetus on the price - because some act as investors. 

One hidden aspect regarding miners other than the miner-investment relationship, and the positive word of mouth, is we must view miners as a positive expense - basically similar to payroll.  Because this data reveals that spending money on mining rewards is far different than capital expenses.  The miner will not sell the coins unless they made a profit, meaning that money spent to miners does not necessarily cause the price to drop.  The price drops when they liquidate coins to pay for electric.  However the miner may be living in the basement, where the expenses are already paid by the household.  Meaning a miner may make a substantial profit off of BBP even if they break even on paper (due to the fact that the electric is a constant given expense where they live regardless of their computer running).

Elaborating on this to be more clear, one aspect of this project is to rank each type of expense as to its ability to pull down our price.  For example, we have :  mining expenses to miners, governance to payroll, governance to charity, mining to poom, mining tithes given to POG, and QT controls (among other things).  This exercise is revealing very interesting things about our project:  Mining rewards to miners are positive - because - their liquidation requires :  psychological profit and for our price to be higher than the electric costs they spent.   Rewards to POOM otoh, immediately drop our price because the miner must sell to recoup the fiat spent (meaning POOM = 1 as far as benefit to biblepay).  Mining rewards = 9 due to word of mouth.  Mining rewards for GSC-POG appear "good", but looking deeper into these - the POG component that the miner tithed to the foundation is another problem.  This means our liquidation for those 2mil per month coins has : expanded our governance budget way beyond .10% initially designed, And worse, those coins hit the market and immediately lower our price.  Making POG also : 1 (bad for biblepay).  Governance percentages:  Although we originally designated 10% cap to charity,  with POG, we have been spending 20% on charity, and with POOM, 40% of gsc, making our monthly budget grossly overspent on charity (50%).  This "sounds" great from a charity perspective, but the problem is, we must be healthy in order to even be in business.  You cant kill the golden calf and expect to be a blessing next month if the whole calf is dead.  So, another thing this simulation reveals:  To run a tight ship and be a bigger blessing, we must take control of our charity expenses and pull the horns in and cap this at a strict 10% per month - no more - to any other budget allocation.  This will limit coins spent (other than the 10%) to not drag down our price (IE all other coins would end up in IT projects, proposals, payroll, and mining).

QT:  QT is another 'feature' that has an entirely different side of it than the proposal alludes to.  From the proposal we said, hey lets take control of our expenses, lets run a tight ship and go up in price.  However, the unintended consequences are this:  we blocked our growth.  In order to have growth (the +1 new user per day we will discuss in this thread) you must have mining expenses.  Above we show mining expenses are not bad - because they are allocated over hundreds of wallets and provide good word of mouth.  So, we ran our users off by trying to save money.  The model shows, with a stagnating attrition level of just -1 UPD, the price goes sideways, and worse, could go down once the users leave.  However, by spending more on mining, with +1 UPD, the price goes north.  (See charts with +1 UPD - Good - BBP).  So I will be recommending that we shut down QT.



Chart 1:  Dash as they are now (Good) - with positive new users per day:



Chart 2:  Dash - in a bad environment - where they increase governance % to 20%, and, with negative user growth per day:



Chart 3:  BBP - in a good environment - with 10% charity budget, and, positive user growth per day:



Chart 4:  BBP - in a bad environment - with 20% charity budget, and negative user growth per day:





Summary of Changes:


- Remove QT (Quantitative Tightening):  This increases our emission back to our original plan.  This will theoretically attract new miners and new users and new investors as word of mouth increases.

- Make each currency unit more expensive:  Back when we had PODC, each currency unit was harder to mine, because we had 300 concurrent PODC users competing in Team Biblepay for RAC.  It is clear that when user count increases *and* it becomes harder to mine, our price goes up.  Therefore we must do things that lower the barrier for miners to enter (lower ABN fees), allow difficulty to increase, and add PODC.

- Lower ABN fees:  Although counter intuitive that with a rising diff, you would expect a *higher* abn, we actually want a higher diff (to make each currency unit more expensive), and we want a lower abn, to bring in as many users as possible.  I recommend lowering ABN to 25,000 to attract more users.  I think we can leave ABN in the code so as to help remove potential botnets.  However, it could be argued that the ABN is over-complicating BBP and it is complicating the pool (and adding requirements for unlocking wallets etc).  Lets talk about this in more detail.

- Reinstate PODC:  Although we removed PODC so as to not have as much code to support, with the above revelation on POG and its negativity for expenses and tithing, I feel we are in a good position to re-enable PODC in our GSC system.  Additionally, there are ways to remove the oracle risk, which I will discuss soon.  I think in phase 1, we can accomplish our short term goals like this:  We write new code to pull in Rosetta CPID RAC into a GSC contract.  We raise the daily GSC payout to 80% for PODC.  We reward Rosetta CPIDs for tasks from the GSC "CancerMining" budget.  We cap each CPIDs reward at a certain RAC (equal to something like 5 computers).  This *helps* prevent users with astronomical RAC from overrunning the rewards in this GSC.  (I know split cpids will occur but we protect more small users this way).    We require team BBP for cancer mining.

- Remove POG - replace with PODC:  Primarily due to users not feeling comfortable with daily tithing, *and* the POG budget being a negative related to exchange liquidation; remove it

- Keep Healing - Healing is bearing Christian fruit; and is only 5% of the daily budget; keep it

- Decrease Charity % back to 10% (Original Design) - Due to the fact that POOM was added, and POG crept in, we have essentially increased our charity budget way beyond 10%.  Its around 10% from governance plus 10% from POG plus 20% for POOM equaling about 40%.  This alone, when plugged in the model creates a death spiral for biblepay.  Its almost as if these expenses will certainly kill our price per month, and the only hope for a recovery is hitting 1 satoshi and losing 90% of our orphans.  Therefore, it is recommended we go back to our original design:  No more than 10% for charity.  How can this be?  This goes hand in hand with the DAC idea; how can we accomplish this and still be a dac?  I recommend we lower our monthly governance charity % to zero (while we pay off our current new exchange deficit), and adjust POOM to be exactly 10% of our monthly budget.  Since poom is new, it accomplishes the charity budget in a decentralized nature already (today).  We can allow compassions credit to work its way to zero and then we temporarily cancel compassion.  In the near future, depending on how POOM works, we can offer Kairos to integrate with POOM.   If POOM fails, we can then talk about  Sanctuaries  decentralizing charity expenses.    For now, this proposal proposes to :    Lower Charity superblock budget to zero, remove POG and tithing, lower Cameroon-Ones POOM budget to exactly 10% of our monthly budget.  If cameroon-one is not used up by the miners, the coins are  burned (as it is already set up now).

- Sanctuary payment/heat mining payment:  Sun asked in the forum thread if sanctuaries are getting too little due to QT & DGW.  On the DGW side, I am a fan of a decreasing reward when the diff is exceedingly high (I think Dash was correct in penalizing an inrush of large hashpower).  Aside from this, with QT removed, our rewards increase dramatically (60% more), and recently last month MIPs proposal won that increases the sanctuary payout by 10% (by decreasing heat mining 5% and decreasing pog 5% - note - this restores the sancs to the original launch parameter that was disturbed by pog).  So I feel we are OK on our current path with Sanc/heat payments.  If anything were to be considered for change in the *future*, we could consider simplifying biblepay by :  first requiring chainlocks (for increased security) then lowering the heat mining reward and raising the PODC reward.  But I feel we can postpone this idea - until after chainlocks are working successfully in prod and we regroup.












2
Production Proposals / New Exchange - Coinsbit
« on: October 19, 2019, 10:07:41 am »
All-

Togo has been searching for new exchanges lately, and out of (I would say, almost all of the top 100 exchanges we either tried to contact or have successfully reached), Coinsbit is one of the few that has replied, talked to us via email, gave us what appears to be a very good offer to be on their exchange, and appears to be a high quality partner.

First I want to say, Im more than a little dissapointed with the past deals, and it would be unprofessional for me to name any specific companies at this point.  But, let me say - Im dissapointed that we have been placed with companies during our launch that failed to meet minimum business practices of honesty and have gone out of business.  Im dissapointed we ended up paying good money for a very limited result for an exchange deal that had almost 0 volume per day and then went out of business.  And then the straw that almost broke our back, we have been unequally yoked with players who are not creating purely real volume and have lower trust scores.  I prayed about this today and asked Jesus to step in.  I have faith, that he will fix all things.

Moving on to the issue at hand, Coinsbit has a trust rating of 8.  They have 20,000 twitter followers.  They have 1+MM similarweb visits on coingecko (Ie traders/users).  They do $250MM or $20,000,000 mm normalized volume (meaning they may be bigger in volume than bittrex).
https://www.coingecko.com/en/exchanges/coinsbit#trust_score

I already explained to Nick, who btw seems to be a very nice guy and appearing to work with us (and Togo spoke to him also on discord) - that we are over budget.  He came down in price for us. 

I view this deal as basically - a very good deal, I dont want to walk away from - and as you all might imagine  - our last exchange deal for quite a while.  If we do this, we need to walk away from new exchanges for a year and pay off our deficit, unless of course God steps in and our price rises significantly over the next 6 months.

The deal is:


.50 BTC - go live right after proposal wins
.50 BTC in BBP
_______________
TOTAL Deal: 1 BTC

Rob will have to front the BTC and BBP; we get to go live by Nov 1st if we agree to these terms.





3
Production Proposals / cameroon-one installment 5 2019
« on: October 19, 2019, 09:55:56 am »
We sponsor 11 cameroon one children totaling $4800 per year.  We have paid $4279 and we owe $521 to be paid up through the end of 2019.

Due to our limited budget, I am asking for 700,000 (IE we will need to enter another proposal next month to cover the remainder).


4
Production Proposals / Payroll Oct 2019
« on: October 19, 2019, 09:46:36 am »
Since we have limited funds for payroll this month, I will only include hours for 'porting POBH to CPU-miner'; capping at 1 mil:

https://github.com/biblepay/cpuminer

AMOUNT: 1 mil


5
Production Proposals / Lower ABN Requirement?
« on: October 02, 2019, 05:13:58 pm »
Shall we change the ABN requirements, Saints?

To be more friendly to new users?


6
Production Proposals / September Payroll (May 2019)
« on: September 21, 2019, 10:16:11 am »
Commits on May 31, 2019
OneClickSanctuary EVO instructions

 
 
masternode setup script for Evo

 
1.4.3.1d-Leisure Upgrade

@biblepay
biblepay committed on May 31
 
Commits on May 27, 2019
1.4.3.1c-Leisure Upgrade

@biblepay
biblepay committed on May 27
 
1.4.3.1b-Leisure Upgrade

@biblepay
biblepay committed on May 27
 
1.4.3.1b-Leisure Upgrade

@biblepay
biblepay committed on May 27
 
Commits on May 20, 2019
1.4.3.1 - Evo RC6 - fix for MacOS compile

 
Commits on May 19, 2019
1.4.3.1 - Evo RC6

@biblepay
biblepay committed on May 19
 
Commits on May 18, 2019
1.4.2.9-Evo RC5

@biblepay
biblepay committed on May 18
 
Commits on May 17, 2019
1.4.2.9-Evo RC4

@biblepay
biblepay committed on May 17
 
1.4.2.9-Evo RC3

@biblepay
biblepay committed on May 17
 
1.4.2.9-Evo RC2

@biblepay
biblepay committed on May 17
 
1.4.2.9-Evo RC1

@biblepay
biblepay committed on May 17
 Commits on May 7, 2019
1.4.2.8b-Leisure upgrade for TestNet

@biblepay
biblepay committed on May 7
 
1.4.2.8-Mandatory upgrade for TestNet

@biblepay
biblepay committed on May 7
 
Commits on May 4, 2019
1.4.2.7-Mandatory Upgrade for TestNet

@biblepay
biblepay committed on May 4
 
Commits on May 3, 2019
1.4.2.6-Mandatory Upgrade for TestNet

@biblepay
biblepay committed on May 3
 
1.4.2.5-Mandatory Upgrade for TestNet

@biblepay
biblepay committed on May 3
 
Merge branch 'master' into develop

MIP
MIP committed on May 3
 
Commits on May 2, 2019
1.4.2.4-Mandatory Upgrade for TestNet

@biblepay
biblepay committed on May 2


Capping at 1.25 MM



7
Production Proposals / Remove Port Restriction on Hosted Sanctuaries
« on: September 15, 2019, 01:31:18 pm »
So this idea is spearheaded by Apollon and I also have heard of this idea from TheSnat before.

The idea is to remove the port restriction on sactuaries, and allow the sanc to be hosted from any port number.

Technically, we know this will work because XAP and BlockLogic (BLTG) are doing it already.

(The port restriction is this:  Dash must run on port 9999 only and if a user hosts from other than 9999, the Masternode will be rejected from the network.  For BiblePay they must run on port 40000).

Dash put the port restriction in to be more corporate friendly for Network Admins - IE - they wanted network admins to know that if port 9999 is to be open, its specifically for Dash traffic.

Initially I was slightly against the idea, when I imagined we would have one sanc per user, I figured each of us could afford the $5 hosting fee per month.

However, as we evolved I have seen another side to this situation:  During downward price spirals some of our users who are cost concious would like to run more than one sanc on a hosted VPS.  From my perspective, I changed my mind to neutral when I experienced a very bad service level with one of my last sanc hosts (not vultr), and I had to hurry and switch to Apollon (thank God they were available at the time).  What Im alluding to is, if removing the port restriction would have given me for example a path to create more instances per vultr node for example, it might have been a life saver.  (I dont mean financially for me, I mean for the sake of the GSC contracts being voted on by my nodes).

In light of this I've become neutral.  I obviously want high performance per node.

Please provide any opinions on this idea, if this will be a terrible move for some reason.

As far as Apollons perspective, they are in business to make money.  I realize our partners need to be healthy and make a profit, and if we lose our partners, we lose our ability to host sancs.  Lets think of this from all angles.

Possible Positive reason:
If less BBP is spent on hosting less is liquidated on the exchange for hosting fees to be paid

Possible Negative reason:
Will we look weak and fragile if we allow this?





8
Production Proposals / August payroll (Apr) 2019
« on: August 17, 2019, 10:23:39 am »
ommits on Apr 29, 2019
1.4.2.3-Mandatory Upgrade for TestNet 

@biblepay
biblepay committed on Apr 29
 
Commits on Apr 28, 2019
1.4.2.2b-Leisure Upgrade for TestNet 

@biblepay
biblepay committed on Apr 28
 
1.4.2.2-Mandatory upgrade for TestNet 

@biblepay
biblepay committed on Apr 28
 
Commits on Apr 26, 2019
1.4.2.1b-Mandatory upgrade for TestNet 

@biblepay
biblepay committed on Apr 26
 
1.4.2.1-Mandatory Upgrade for TestNet 

@biblepay
biblepay committed on Apr 26
 
Commits on Apr 25, 2019
Merge branch 'master' into develop 

MIP
MIP committed on Apr 25
 
Commits on Apr 23, 2019
1.4.2.0-Mandatory Upgrade for TestNet 

@biblepay
biblepay committed on Apr 23
 
Merge branch 'master' into develop 

MIP
MIP committed on Apr 23


Commits on Apr 22, 2019
1.4.1.9-Leisure upgrade for TestNet 

@biblepay
biblepay committed on Apr 22
 
Commits on Apr 21, 2019
Merge branch 'master' into develop 

MIP
MIP committed on Apr 21
 
Commits on Apr 20, 2019
1.4.1.8-Mandatory Upgrade for TestNet 

@biblepay
biblepay committed on Apr 20
 
Commits on Apr 18, 2019
Merge branch 'master' into develop 

MIP
MIP committed on Apr 18
 
Commits on Apr 17, 2019
1.4.1.7 - Mandatory Upgrade for TestNet 

@biblepay
biblepay committed on Apr 17
 
Commits on Apr 12, 2019
1.4.1.6-Mandatory Upgrade for TestNet 

@biblepay
biblepay committed on Apr 12
 
Commits on Apr 10, 2019
1.4.1.5b-Leisure Upgrade 

@biblepay
biblepay committed on Apr 10
 
1.4.1.5-Mandatory Upgrade for TestNet 

@biblepay
biblepay committed on Apr 10
 
Commits on Apr 9, 2019
1.4.1.4-Mandatory Upgrade for TestNet 

@biblepay
biblepay committed on Apr 9
 
Commits on Apr 5, 2019
1.4.1.3-Mandatory Upgrade for TestNet 

@biblepay
biblepay committed on Apr 5
 
Merge branch 'master' into develop 

MIP
MIP committed on Apr 5
 
Commits on Apr 4, 2019
1.4.1.2b-TestNet Mandatory Upgrade 

@biblepay
biblepay committed on Apr 4
 
1.4.1.2-Mandatory Upgrade for TestNet 

@biblepay
biblepay committed on Apr 4
 
1.4.1.1-Mandatory Upgrade for TestNet 

@biblepay
biblepay committed on Apr 4
 
Commits on Apr 3, 2019
1.4.1.0-Leisure Upgrade for TestNet 

@biblepay
biblepay committed on Apr 3
 
1.4.0.9d-TestNet Leisure Upgrade 

@biblepay
biblepay committed on Apr 3
 
Commits on Apr 2, 2019
1.4.0.9c-TestNet Mandatory Upgrade 

@biblepay
biblepay committed on Apr 2
 
1.4.0.9b-TestNet Mandatory Upgrade 

@biblepay
biblepay committed on Apr 2
 
1.4.0.9-TestNet Mandatory Upgrade 

@biblepay
biblepay committed on Apr 2
 
Merge branch 'master' into develop 

MIP
MIP committed on Apr 2
 
Commits on Apr 1, 2019
1.4.0.8-TestNet Mandatory Upgrade 

@biblepay
biblepay committed on Apr 1


This was approx 120 hours - capping @ 1.5 MM this month due to budget constraints.


9
We have an offer to be listed from Paul at Tokok.com for 2btc.

Tokok does 442 MM per day - see CoinGecko:
https://www.coingecko.com/en/exchanges/tokok
CMC:
https://coinmarketcap.com/exchanges/tokok/

If listed, Rob would provide the initial funding by loaning BBP the 2btc.
BBP would remunerate Rob in 12 payments of .16 btc each.

This is a competing proposal to provide entrance into the Asian market.
Impho, I recommend the sancs to vote on either one or the other (but not both) as I don't think we can afford both proposals.

Please evaluate Tokok, as we want the most honest and liquid exchange in Asia for BBP.


_____________________________________________________________________________________________________

The gross deal (Updated August 29th 2019 after superblock 141450 paid):

** Note: I have inspected the New Exchange Fund as of 8-29-19 and found we have .0797 BTC and 1,350,000 in the treasury (see New Exchange Fund Report).  In light of this I will post a credit of .0797 to Rob as payment #2 and offer Tokok a 1,350,000 airdrop- to reconcile this exactly to the penny **


- Listing fee - 2 BTC (goes directly to Tokok)
- Airdrop campaign/PR - Tokok delivers 1.35MM to Tokok Traders





Payments to Tokok:
Will pay 2btc for listing fee
Will pay 1,350,000 For Airdrop




Payments from Superblocks back to Rob for this deal:

_________________________________________________________________________________________________________________

Payment #1 -  3,647,790.00 (Paid in superblock  141450) -                                                               [.211 BTC PAID ]
Payment #2 - .0797 BTC - (From New Exchange Fund to Rob)                                                          [.0797 btc paid]
Payment #3 - Adding Proposal for 1,000,000 bbp for September 2019                                          [Not cashed yet]
Payment #4 - Proposal entered in Oct 2019 - 1,000,000 bbp                                                           [Not cashed yet]



10
Production Proposals / FUBT Exchange
« on: August 15, 2019, 06:15:22 pm »
** Deal to List BiblePay with FUBT Exchange - Hong Kong **



I've been in contact with Mr. Yue and Nick Lee from FUBT for one year about potentially listing BiblePay.

A year ago the price quote was too high (IE over 5 bitcoins).

Over the last few months, Mr. Yue had quoted me 3 BTC to list, and I told him we would continue to evaluate their platform as our next exchange and continue to save up funds for our next exchange.

Over the last week, I started talking to Nick.  Nick explained that out of the 3 BTC fee, FUBT will spend a certain amount of money on promoting a new coin (IE they reach out to 50 media companies, and blast a summary of the coin, and promote it for a certain number of days in Asia).  Nick estimates the PR to be worth around $5000~ (or up to 1btc depending on its reception level).

Recently, our coin has been reviewed by FUBT's coin quality assessment group and they consider us to be an "A" grade coin (similar to SouthXChanges ranking system).  They again approached us and re-quoted us a listing for 6btc.  I explained it is out of the ballpark.

Recently, Nick explained to me he can only guarantee the 3 btc fee for a short period of time and we may lose our discount status if we don't try to make an offer soon.

I agreed to take a look at FUBT this month and attempt to create a deal that may possibly work with BiblePay.

FUBT does approx $500 mil per day total volume according to coinmarketcap and coingecko, (not the gecko normalized volume).  From looking at a comparison between Tokok, FUBT, Bittrex and SouthXChange, FUBT appears to be about 50* bigger than southxchange.  Nick explained to me they have 2 million registered traders at FUBT. 

https://www.coingecko.com/en/exchanges/fubt
https://coinmarketcap.com/exchanges/fubt/

Estimating the size of this investment, 3btc ($35,000), I estimate that we would see a potential increase of $5 - $10,000 per day in trading volume (based on similar coins to BiblePay) and this would potentially lead to a market cap increase in BiblePay, *potentially* paying off the investment within a short duration.  (Nick tends to think we would be received well in Asia and coins like us trade more than $20K per day, but this is speculative.)

I feel this move into Asia is something BiblePay currently needs, as we trade almost exclusively in the US.  I think the 2 mil additional accounts complement our needs to a high degree.

In light of this, if the sanctuaries agree, I am offering to help this listing along with the following offer:

If this proposal is voted in and the Security Check passes (this is an internal freshdesk ticket with FUBT senior management to verify the exchange proposal is signed and agreed upon by BiblePay and FUBT):
Rob sends FUBT 3 btc from his personal account (lending BBP 3 btc)
Rob enters a 12 part proposal to recoup .25btc per month until the 3 btc is paid back

FUBT Provides:

- Listing BTC/BBP trading Pair
- 1BTC worth of promotion (Media blitz with 50 media outlets, 1-2* depending on market appreciation)
- At least 4 mandatory upgrades per year with no fees (I verified this with Nick)
- The go live would be towards the end of September 2019 and media blitz around mid September

** If anyone has anything negative to report about FUBT please report it now **



Proposal Payment dispursement breakdown:

Payment 1 of 12:
BTC @ 10567 : .25BTC * 10567 / .000724 = 3,647,790 BBP

(Note, as each month occurs I will update the remaining payments until we hit 3 btc)



11
Production Proposals / Compassion - July 2019
« on: July 26, 2019, 09:37:07 pm »
We sponsor 55 compassion children @$2090.00 per month.
Seeking 1 mil.


12
Production Proposals / Cameroon One Installment 4 2019
« on: July 26, 2019, 09:16:17 pm »
We have 11 children with cameroon one, we have donated approx $2393 in 2019, and our annual due is $4026.00.

Requesting 2 million.


13
Production Proposals / July payroll (March) 2019
« on: July 26, 2019, 09:05:51 pm »
Commits on Mar 31, 2019
1.4.0.7d-TestNet mandatory upgrade 

@biblepay
biblepay committed on Mar 31
 
1.4.0.7c-Testnet Mandatory Upgrade 

@biblepay
biblepay committed on Mar 31
 
1.4.0.7b-Testnet mandatory upgrade 

@biblepay
biblepay committed on Mar 31
 
1.4.0.7-TestNet Mandatory Upgrade 

@biblepay
biblepay committed on Mar 31
 
Commits on Mar 30, 2019
Merge branch 'master' into develop 
 
1.4.0.6b-TestNet Mandatory Upgrade 

@biblepay
biblepay committed on Mar 30
 
1.4.0.6-TestNet Mandatory Upgrade 

@biblepay
biblepay committed on Mar 30
 
Commits on Mar 29, 2019
1.4.0.5 - TestNet Mandatory Upgrade 

@biblepay
biblepay committed on Mar 29
 
Commits on Mar 28, 2019
1.4.0.4-TestNet Mandatory Upgrade 

@biblepay
biblepay committed on Mar 28
 
Commits on Mar 27, 2019
1.4.0.3-TestNet Mandatory Upgrade 

@biblepay
biblepay committed on Mar 27
 
Merge branch 'master' into develop 

Commits on Mar 26, 2019
1.4.0.2-TestNet Mandatory Upgrade 

@biblepay
biblepay committed on Mar 26
 
Commits on Mar 25, 2019
1.4.0.1d-Testnet RC 

@biblepay
biblepay committed on Mar 25


Commits on Mar 24, 2019
1.4.0.1c-TestNet RC 

@biblepay
biblepay committed on Mar 24
 
1.4.0.1b-Testnet RC 

@biblepay
biblepay committed on Mar 24
 
1.4.0.1-Testnet Release Candidate 

@biblepay
biblepay committed on Mar 24
 
Commits on Mar 22, 2019
1.2.0.1o-Genesis 

@biblepay
biblepay committed on Mar 22
 
Commits on Mar 20, 2019
1.2.0.1n-Genesis 

@biblepay
biblepay committed on Mar 20
 
1.2.0.1m-Genesis 

@biblepay
biblepay committed on Mar 20
 
Commits on Mar 18, 2019
1.2.0.1l-Genesis 

@biblepay
biblepay committed on Mar 18
 
Commits on Mar 16, 2019
1.2.0.1k - Genesis 

@biblepay
biblepay committed on Mar 16
 
Commits on Mar 12, 2019
1.2.0.1j-Genesis 

@biblepay
biblepay committed on Mar 12
 
Commits on Mar 10, 2019
1.2.0.1i-Genesis 

@biblepay
biblepay committed on Mar 10
 
Commits on Mar 6, 2019
1.2.0.1-Genesis 

@biblepay
biblepay committed on Mar 6
 
Commits on Mar 5, 2019
1.2.0.1g-Genesis 

@biblepay
biblepay committed on Mar 5
 
1.2.0.1f-Genesis 

@biblepay
biblepay committed on Mar 5
 
1.2.0.1e-Genesis 

@biblepay
biblepay committed on Mar 5
 
Commits on Mar 4, 2019
1.2.0.1d-Genesis 

@biblepay
biblepay committed on Mar 4
 
1.2.0.1c-Genesis 

@biblepay
biblepay committed on Mar 4
 1   
1.2.0.1b-Genesis 

@biblepay
biblepay committed on Mar 4
 
1.2.0.1-Genesis 

@biblepay
biblepay committed on Mar 4


120 hours = $4800 - capping at 3 mil.


14
Pre-Proposal Discussion / Foundation Donation Empowerment Feature
« on: June 30, 2019, 08:19:37 pm »
So that BiblePay can maximize the good that it does globally and help as many orphans as possible, I am proposing that we add a feature that will allow a foundation donor to designate which partner charity a foundation donation gets spent on, if they feel they want it spent on one of our partner charities other than Compassion.com.   (By default all foundation revenue gets liquidated and sent to compassion.com).

(One example of how we will sponsor more orphans than our monthly budget + monthly donations currently allows for, is we have a donor that is willing to pay for a certain number of Kenyan orphans at HFOC, but BiblePay currently has too small of a budget to handle the new Kenyan orphans.  So in this case, the donor will send a donation to the foundation once per month, and BiblePay will forward the BBP funds from the donation to HFOC, allowing the relationship to continue.  This will give BBP more of a global monthly sponsorship count also, helping us become more of a globally recognized charity - important when we make new partners and also for due diligence with integrations and exchanges).

This feature will work with both POG donations or standard donations.

Note that the donation amount must be greater than $100 USD (or approx 250,000 BBP) to use the feature (as clerical work is required to store the transaction and liquidate the transaction).

The user must direct the funds to go to a currently integrated Charity such as:  Compassion, Kairos Childrens Fund, Cameroon One, BLOOM, Side by Side Ugandan Women,  HFOC (as these charities accept BiblePay currently).

When the user designates a specific charity, BiblePay will store a record (for 10 years) of the revenue and expense.   This will allow us to produce accountability reports and also report a greater net giving total as a community.

To use the feature, first send a donation to the foundation using either our standard send money checkbox (or a POG donation) of > 250,000 BiblePay (or $100, whichever is less).  Copy the TXID to the clipboard.  From the Pool, navigate to Account | Donation Director.  From this page, paste the TXID of the transaction and select the designated Target charity from the dropdown list.  Click Submit.

Note: The donation director record must be received before 3 days before the current month superblock is paid, otherwise the record will be designated for the following month.

To see the donation director records, click : Reports | Donation Director Records.



 

15
The ABN feature reduces the liklihood of bot-net mining activity against BiblePay.

Rob wants to ensure Security is maintained and our difficulty level never falls below 5000.

Should we re-enable ABN in small steps, starting with a 1,000 BBP requirement?

Then, if difficulty remains > 5000, we can increase our ABN requirement in steps weekly maintaining diff around 10K or more.


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