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
1
Production 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
1.1.5.6c-Leisure Upgrade 

@biblepay
biblepay committed on Sep 30
 
Commits on Sep 27, 2018
1.1.5.6b-Leisure Upgrade 

@biblepay
biblepay committed on Sep 27
 
Commits on Sep 26, 2018
1.1.5.6-Leisure Upgrade (Mandatory for Sancs) 

@biblepay
biblepay committed on Sep 26
 
Commits on Sep 24, 2018
1.1.5.5d-Leisure 

@biblepay
biblepay committed on Sep 24
 
Commits on Sep 22, 2018
1.1.5.5c-Leisure Upgrade 

@biblepay
biblepay committed on Sep 22
 
1.1.5.5b-Leisure Upgrade 

@biblepay
biblepay committed on Sep 22
 
1.1.5.5-Leisure Upgrade (Mandatory for TestNet) 

@biblepay
biblepay committed on Sep 22
 
Commits on Sep 18, 2018
1.1.5.4b-Leisure 

@biblepay
biblepay committed on Sep 18
 
1.1.5.4-Leisure (Mandatory for TestNet) 

@biblepay
biblepay committed on Sep 18
 
Commits on Sep 17, 2018
1.1.5.3b-Leisure 

@biblepay
biblepay committed on Sep 17
 
Commits on Sep 16, 2018
1.1.5.3-Leisure (Mandatory for TestNet) 

@biblepay
biblepay committed on Sep 16
 
Commits on Sep 15, 2018
1.1.5.2b-Leisure 

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

@biblepay
biblepay committed on Sep 15
 
1.1.5.2-Leisure Upgrade 

@biblepay
biblepay committed on Sep 15
 
1.1.5.1-Leisure Upgrade (Mandatory for TestNet) 

@biblepay
biblepay committed on Sep 15
 
Commits on Sep 14, 2018
1.1.5.0d-Leisure Upgrade 

@biblepay
biblepay committed on Sep 14
 
1.1.5.0.c-Leisure Upgrade 

@biblepay
biblepay committed on Sep 14


Commits on Sep 13, 2018
1.1.5.0b-Leisure Upgrade 

@biblepay
biblepay committed on Sep 13
 
1.1.5.0-Leisure (Mandatory for TestNet) 

@biblepay
biblepay committed on Sep 13
 
Commits on Sep 7, 2018
1.1.4.9-Leisure Upgrade (Mandatory for Testnet) 

@biblepay
biblepay committed on Sep 7
 
Commits on Sep 2, 2018
1.1.4.8b-Leisure 

@biblepay
biblepay committed on Sep 2
 
1.1.4.8-Leisure Upgrade (Mandatory for TestNet) 

@biblepay
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.


2
Production 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:
http://pool.biblepay.org/SAN/expenses/BiblePay_audit_2018.pdf

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.


3
Production 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.

4
Active Discussions / 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:

https://wiki.biblepay.org/Proof-of-Giving-II

And the summary for beginners:
https://wiki.biblepay.org/Proof-of-Giving-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.

POOL ROUND MECHANICS:
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.


AUTOMATIC TITHING:

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.


MANUAL TITHING:


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.


CHECKING POG DIFFICULTY:

To see the difficulty parameters, type 'getmininginfo'.


CHECKING HISTORICAL POG GIVING:

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.

CHECKING THE POOL:

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.

HOW TO SET NICKNAME:
In your biblepay.conf file set the key 'nickname=my_nickname' and restart the wallet.


WALLET VERSION:
Upgrade to 1.1.6.2+.  Start with '-testnet=1' flag.


RPC COMMANDS:

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.





TEST CASES:

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.


5
Pre-Proposal Discussion / 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:
https://wiki.biblepay.org/Proof-of-Giving-II
And this wiki:
https://wiki.biblepay.org/Proof-of-Giving-for-Beginners



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 orphanstats.com, 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.

6
Pre-Proposal Discussion / Trust level of Proof-of-orphan-mining
« on: November 28, 2018, 02:09:39 pm »
I'm trying to gauge the public level of reception if we had proof-of-orphan-mining available.

POOM is an idea where BiblePay starts an additional website called orphanstats.com.  This sites sole purpose would be to gather statistics on private orphan sponsorships (IE normal home users who sponsor personal children at compassion.com).  Then, we would program a custom BiblePay API to allow the sanctuaries to query (from orphanstats.com) - the orphan statistics (such as the Orphan ID list per User ID, the monthly commitment amount per User etc).  Using this info, BiblePay Core could potentially reward users out of the PODC budget for monthly sponsorships, expanding biblepay and saving net electricity.

However, the primary downside to this is that the orphanstats.com method of harvesting the child information per user would be logging in to your private compassion.com account with a long key (a keypair created by orphanstats), then orphanstats would scan the list of orphan IDs once per night and save the info per User ID and log out (programatically).  Although we would publically promise to not scan any other information than the numeric orphan ID of each child and then log out, obviously this system requires trust.

So please tell us your opinion:  If you trust that we would not look at any other info, vote Yes, If you would like to see this system in prod.

If you would only allow this type of scan if you created a new compassion account using "BiblePay Branch Office", a PO BOX, and a blank phone number, vote the corresponding option.

Another option is if we had two database administrators - verifying the data collected includes no other fields; if you feel safe in that case, please vote that way.

Otherwise please tell us this is a bad idea by voting No.


7
Pre-Proposal Discussion / Mass Adoption for BiblePay
« on: November 21, 2018, 10:57:17 am »
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 - 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.

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 orphanstats.com, 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.


8
We are sponsoring 100 recurring orphans from compassion (@ $3800.00 per month).

This is equal to 11.8MM BBP for the month of November 2018. (3800/.000321).

Since we have a projected 5.11 month credit on our account and we have many proposals this month I am seeking 1 million bbp.



9
Archived Proposals / November IT payroll
« on: November 19, 2018, 03:31:24 pm »

In August I worked on BiblePay for 112 hours. 
Invoice: 112*40=$4480/.000321=13.9MM bbp.

I am seeking 2 million bbp (capping the amount to allow other IT + Jaaps reimbursements this month be voted in).


Commits on Aug 21, 2018
1.1.4.5b-Leisure Upgrade 


Commits on Aug 28, 2018
1.1.4.7b-NOOP 

@biblepay
biblepay committed on Aug 28
 
1.1.4.7-Leisure Upgrade 

@biblepay
biblepay committed on Aug 28
 
Commits on Aug 26, 2018
1.1.4.6h - Leisure Upgrade 

@biblepay
biblepay committed on Aug 26
 
1.1.4.6g-Leisure Upgrade 

@biblepay
biblepay committed on Aug 26
 
Commits on Aug 24, 2018
1.1.4.6f-Leisure Upgrade 

@biblepay
biblepay committed on Aug 24
 
Commits on Aug 23, 2018
1.1.4.6e-Leisure Upgrade 

@biblepay
biblepay committed on Aug 23
 
1.1.4.6d-Leisure Upgrade 

@biblepay
biblepay committed on Aug 23
 
1.1.4.6c-Leisure Upgrade 

@biblepay
biblepay committed on Aug 23
 
Commits on Aug 22, 2018
1.1.4.6b-Leisure Upgrade 

@biblepay
biblepay committed on Aug 22
 
1.1.4.6-Leisure Upgrade 

@biblepay
biblepay committed on Aug 22
 





@biblepay
biblepay committed on Aug 21
 
Commits on Aug 14, 2018
1.1.4.5-Leisure 

@biblepay
biblepay committed on Aug 14
 
Commits on Aug 12, 2018
1.1.4.4b-Leisure Upgrade 

@biblepay
biblepay committed on Aug 12
 
Commits on Aug 10, 2018
1.1.4.4-Leisure Upgrade 

@biblepay
biblepay committed on Aug 10
 
Commits on Aug 4, 2018
1.1.4.3 - Leisure Update 

@biblepay
biblepay committed on Aug 4
 
1.1.4.2 - Leisure Update 

@biblepay
biblepay committed on Aug 4

10
Pre-Proposal Discussion / Add Proof-of-Giving
« on: November 19, 2018, 01:12:10 pm »
Let us discuss the viability of POG, as the future mining algorithm for BiblePay.

POG is an extension of POBH(Our version of POW), and promotes mass adoption.

Note that I personally love what we have achieved with PODC, but it appears PODC has caused some attrition in our community overall.  It's hard to say specifically, but some feedback is telling us that we are too hard to set up and maintain in our mining environment.  New users don't have the stake for the UTXO, and some average home users feel they do not want to learn (nor care) about all the acryonyms we throw around with PODC.  The average user does not want to learn about RAC, or run multiple programs, unfortunately. 

The goal is to create a friendly environment where the average user may download biblepay and launch it in a plug n play environment and start mining without a learning curve.  Then they can tell their friends about us.  Also, for us to fairly reward everyone rich and poor with a mining reward.  POG appears to do this, in the sense that it rewards those who tithe into tranches.  It gives us an internal pool, so the user does not need to rely on an external pool for rewards (meaning that every POG miner is rewarded for mining without learning about pools).

If we can create an environment with a positive growth rate of a few new miners per day, we will potentially be on our way to creating a successful long term future for our orphans and our community.

Please read:

https://wiki.biblepay.org/Proof-of-Giving


11
Pre-Proposal Discussion / Add Proof-Of-Orphan-Mining
« on: November 13, 2018, 11:38:51 am »
Let's all discuss the implications of proof-of-orphan-mining if added to BiblePay.

From a high level, this would allow a new user to set up the wallet for mining in a much simpler way, and reward the masses for sponsoring personal orphans.


Please see this information first:

https://wiki.biblepay.org/Concept_POOM


12
Pre-Proposal Discussion / Should we remove the BOINC Team Blacklist (PODC)?
« on: November 07, 2018, 12:19:16 pm »
If we remove the blacklist, members of Gridcoin and Byteball for example will be eligibile for PODC rewards.

13
BiblePay discussion / Integrity Of BiblePay
« on: October 21, 2018, 11:49:37 pm »
I'm adding this poll to get a general feel about our trust level as a coin, and trust level for our algorithm.


14
This is a general poll in response to a message I received where the person claimed I was not operating in a democratic manner, and in general, an attempt to gather the feel of the trust level of the community.


15
Archived Proposals / October Payroll and IT Expenses
« on: October 19, 2018, 01:14:24 pm »
To partially fund some of my own programming hours, I would like to submit Github commits for the core biblepay wallet from
May 1 2018 through June 30th 2018 (I am including two months of work this month since I spent at least 40 hours moving between the end of May and during June):

Commits on Jun 18, 2018
biblepay_sk update 

@OrbisPictus
OrbisPictus committed on Jun 18
 
Commits on Jun 16, 2018
1.1.3.1b-Leisure Upgrade 

@biblepay
biblepay committed on Jun 16
 
1.1.3.1-Leisure Upgrade 

@biblepay
biblepay committed on Jun 16
 
Commits on Jun 15, 2018
1.1.3.0 - Leisure Upgrade 

@biblepay
biblepay committed on Jun 15
 
1.1.2.8b-Leisure Upgrade 

@biblepay
biblepay committed on Jun 15
 
1.1.2.8-Leisure Upgrade 

@biblepay
biblepay committed on Jun 15
 
Commits on Jun 13, 2018
1.1.2.7-Leisure Upgrade 

@biblepay
biblepay committed on Jun 13
 
Commits on Jun 12, 2018
1.1.2.6-Leisure 

@biblepay
biblepay committed on Jun 12
 
Commits on Jun 11, 2018
1.1.2.5b-Leisure Upgrade 

@biblepay
biblepay committed on Jun 11
 
1.1.2.5 - Leisure upgrade, Testnet version for June Mandatory Release 

@biblepay
biblepay committed on Jun 11
 
Commits on May 9, 2018
1.1.2.4c-Leisure Upgrade 

@biblepay
biblepay committed on May 9

Commits on Jun 29, 2018
1.1.3.6-Leisure Upgrade 

@biblepay
biblepay committed on Jun 29
 
Commits on Jun 28, 2018
1.1.3.5b-Leisure Upgrade 

@biblepay
biblepay committed on Jun 28
 
1.1.3.5-Leisure Upgrade 

@biblepay
biblepay committed on Jun 28
 
Commits on Jun 26, 2018
1.1.3.4-Leisure Upgrade 

@biblepay
biblepay committed on Jun 26
 
Merge pull request #27 from thesnat21/master 

@biblepay
biblepay committed on Jun 26
 
Merge pull request #26 from OrbisPictus/patch-2 

@biblepay
biblepay committed on Jun 26
 
Merge pull request #18 from sunk818/patch-1 

@biblepay
biblepay committed on Jun 26
 
Merge pull request #17 from biblepay/add-code-of-conduct-1 

@biblepay
biblepay committed on Jun 26

 
Commits on Jun 20, 2018
1.1.3.3-Leisure Upgrade 

@biblepay
biblepay committed on Jun 20
 
Commits on Jun 19, 2018
1.1.3.2-Leisure 

@biblepay
biblepay committed on Jun 19

Maintained BiblePay Pool in May (as related to assisting users with writing orphans, paying for upvoted letters, and code changes
related to orphan business objects):  16 hours total


For a grand total programming time of
   (40 hrs per week * 4 weeks) = 160 hours @ 40.00 per hour = $6400 (over two months)

For a Grand Total Proposal of :  $6,400.00

Equaling:

?6471.00/.000515 (CoinMarketCap) = 12.5 million biblepay
Since I don't want to exceed 50% of the IT budget, I'll cap this proposal at 3.5 million and gift the rest to biblepay.


Thank you for your consideration.


Pages: [1] 2 3 4 5