91
Archived Proposals / May compassion recurring sponsorships 2019
« on: May 20, 2019, 01:06:40 PM »
We currently sponsor 55 @ $2090 per month.
Requesting 3.22MM.
Requesting 3.22MM.
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.
92
Archived Proposals / May payroll (Jan)
« on: May 17, 2019, 01:38:14 PM »
1.1.8.5-Mandatory Upgrade …
@biblepay
biblepay committed on Jan 27
5
Commits on Jan 23, 2019
1.1.8.4b-Leisure Upgrade …
@biblepay
biblepay committed on Jan 23
1.1.8.4-Leisure Upgrade …
@biblepay
biblepay committed on Jan 23
Commits on Jan 21, 2019
1.1.8.3b-Leisure Upgrade …
@biblepay
biblepay committed on Jan 21
1.1.8.3-Leisure Upgrade …
@biblepay
biblepay committed on Jan 21
Commits on Jan 14, 2019
1.1.8.2-Leisure Upgrade …
@biblepay
biblepay committed on Jan 14
1.1.8.1c-Leisure Upgrade …
@biblepay
biblepay committed on Jan 14
Commits on Jan 13, 2019
1.1.8.1b-Leisure Upgrade …
@biblepay
biblepay committed on Jan 13
1.1.8.1-Leisure Upgrade …
@biblepay
biblepay committed on Jan 13
Commits on Jan 12, 2019
1.1.8.0b-Leisure Upgrade …
@biblepay
biblepay committed on Jan 12
1.1.8.0-Leisure Upgrade …
@biblepay
biblepay committed on Jan 12
Commits on Jan 7, 2019
1.1.7.9b-Leisure Upgrade …
@biblepay
biblepay committed on Jan 7
Commits on Jan 6, 2019
1.1.7.9-Leisure Upgrade …
@biblepay
biblepay committed on Jan 6
Commits on Jan 4, 2019
1.1.7.8q-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
1.1.7.8p-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
1.1.7.8o-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
1.1.7.8n-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
1.1.7.8m-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
1.1.7.8l-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
1.1.7.8k-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
1.1.7.8j-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
1.1.7.8i-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
Commits on Jan 3, 2019
1.1.7.8h-Leisure Upgrade …
@biblepay
biblepay committed on Jan 3
1.1.7.8g-Leisure Upgrade …
@biblepay
biblepay committed on Jan 3
1.1.7.8f-Leisure Upgrade …
@biblepay
biblepay committed on Jan 3
1.1.7.8e-Leisure Upgrade …
@biblepay
biblepay committed on Jan 3
1.1.7.8d-Leisure Upgrade …
@biblepay
biblepay committed on Jan 3
1.1.7.8c-Leisure Upgrade …
@biblepay
biblepay committed on Jan 3
1.1.7.8b - Leisure Upgrade …
@biblepay
biblepay committed on Jan 3
1.1.7.8-Leisure Upgrade …
@biblepay
biblepay committed on Jan 3
Commits on Jan 2, 2019
1.1.7.7c-Leisure Upgrade …
@biblepay
biblepay committed on Jan 2
1.1.7.7b-Leisure Upgrade …
@biblepay
biblepay committed on Jan 2
Merge branch 'master' of https://github.com/biblepay/biblepay
@biblepay
biblepay committed on Jan 2
1.1.7.7 - Leisure Upgrade …
@biblepay
biblepay committed on Jan 2
Merge pull request #63 from biblepay/develop …
@biblepay
biblepay committed on Jan 2
Merge branch 'master' into develop
@biblepay
biblepay committed on Jan 2
Commits on Jan 1, 2019
Added further error handling to Win ShellCommand in case boinccmd fails
=-=-=-=-=-=-
140 hours
Capping at 3,000,000
@biblepay
biblepay committed on Jan 27
5
Commits on Jan 23, 2019
1.1.8.4b-Leisure Upgrade …
@biblepay
biblepay committed on Jan 23
1.1.8.4-Leisure Upgrade …
@biblepay
biblepay committed on Jan 23
Commits on Jan 21, 2019
1.1.8.3b-Leisure Upgrade …
@biblepay
biblepay committed on Jan 21
1.1.8.3-Leisure Upgrade …
@biblepay
biblepay committed on Jan 21
Commits on Jan 14, 2019
1.1.8.2-Leisure Upgrade …
@biblepay
biblepay committed on Jan 14
1.1.8.1c-Leisure Upgrade …
@biblepay
biblepay committed on Jan 14
Commits on Jan 13, 2019
1.1.8.1b-Leisure Upgrade …
@biblepay
biblepay committed on Jan 13
1.1.8.1-Leisure Upgrade …
@biblepay
biblepay committed on Jan 13
Commits on Jan 12, 2019
1.1.8.0b-Leisure Upgrade …
@biblepay
biblepay committed on Jan 12
1.1.8.0-Leisure Upgrade …
@biblepay
biblepay committed on Jan 12
Commits on Jan 7, 2019
1.1.7.9b-Leisure Upgrade …
@biblepay
biblepay committed on Jan 7
Commits on Jan 6, 2019
1.1.7.9-Leisure Upgrade …
@biblepay
biblepay committed on Jan 6
Commits on Jan 4, 2019
1.1.7.8q-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
1.1.7.8p-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
1.1.7.8o-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
1.1.7.8n-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
1.1.7.8m-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
1.1.7.8l-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
1.1.7.8k-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
1.1.7.8j-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
1.1.7.8i-Leisure Upgrade …
@biblepay
biblepay committed on Jan 4
Commits on Jan 3, 2019
1.1.7.8h-Leisure Upgrade …
@biblepay
biblepay committed on Jan 3
1.1.7.8g-Leisure Upgrade …
@biblepay
biblepay committed on Jan 3
1.1.7.8f-Leisure Upgrade …
@biblepay
biblepay committed on Jan 3
1.1.7.8e-Leisure Upgrade …
@biblepay
biblepay committed on Jan 3
1.1.7.8d-Leisure Upgrade …
@biblepay
biblepay committed on Jan 3
1.1.7.8c-Leisure Upgrade …
@biblepay
biblepay committed on Jan 3
1.1.7.8b - Leisure Upgrade …
@biblepay
biblepay committed on Jan 3
1.1.7.8-Leisure Upgrade …
@biblepay
biblepay committed on Jan 3
Commits on Jan 2, 2019
1.1.7.7c-Leisure Upgrade …
@biblepay
biblepay committed on Jan 2
1.1.7.7b-Leisure Upgrade …
@biblepay
biblepay committed on Jan 2
Merge branch 'master' of https://github.com/biblepay/biblepay
@biblepay
biblepay committed on Jan 2
1.1.7.7 - Leisure Upgrade …
@biblepay
biblepay committed on Jan 2
Merge pull request #63 from biblepay/develop …
@biblepay
biblepay committed on Jan 2
Merge branch 'master' into develop
@biblepay
biblepay committed on Jan 2
Commits on Jan 1, 2019
Added further error handling to Win ShellCommand in case boinccmd fails
=-=-=-=-=-=-
140 hours
Capping at 3,000,000
93
Archived Proposals / CAMEROON ONE May 2019
« on: May 17, 2019, 01:31:25 PM »
We have 11 children with cameroon one, we have donated $893 in 2019, and our annual due is $4026.00.
Requesting 5 million to shore up the deficit.
Requesting 5 million to shore up the deficit.
94
Archived Proposals / Whale Revival
« on: May 15, 2019, 07:40:09 PM »
I'm considering the idea of starting an Orphan Whale Fundraiser. I'm doing this partially because I feel we as a society are entering into the end times (Matthew 6:19, do not store treasures on earth but in heaven), (Rev 3:17 Hoarding in the last days), 1 Timothy 6:17 (do good with your blessings), and therefore I feel as if I should give back my retirement account back to the orphans (or to other good causes).
Obviously, this could be done as an individual alone, but I think that if we have a chance to design this fundraiser to 'increase the impact of the deal' where it makes a positive impact for BiblePay, and also for the giver then it is better to do this as a team for biblepay than alone.
Also, I have been reaching out to two of our vendors who offer Orphan early-termination insurance, meaning that they both guarantee the orphan will not be dropped from the benefits program if we pick them up and drop them (they will be subsidized by the insurance they carry or moved to another beneficiary). Both Compassion.com and CAMEROON ONE offer this.
As far as a personal tax deduction, I believe it will be possible to receive the deduction if you give to Cameroon One. As they will allow the check to be sent to them, and the orphan to be in the BiblePay account. Compassion on the other hand does not accept checks from third parties therefore the tax deduction is not possible with them.
So here is what I am thinking as a rough idea:
I ask the community for an idea of how many orphans our whales are willing to sponsor each.
I agree to match an equal amount of BBP/USD to sponsor an equal amount of orphans (IE I match the whales commitments).
BiblePay sponsors an equal amount of orphans out of that monthly superblock also.
We then increase our orphan count by 1/6th of that number (IE we adhere to our 6 month buffer). After BiblePay can no longer afford to pay, we scale back.
So an example looks like this:
Whales 1-5 decide to sponsor 40 orphans ($1600).
Rob matches this number (40) @ $1600.
The money raised goes directly to Cameroon One and Compassion (and those that pay cameroon one receive a tax deduction receipt).
We enter a proposal for BiblePay for $1600 that month also (benefiting 40 orphans).
With this combined action, we receive total funds to sponsor 120 children / 6 months = 20 new orphans.
That same month, we sponsor N from Cameroon and Y from Compassion (depending on how many went with Cameroon).
BiblePay assumes liability for the children at that point going forward.
Note that the whales do not receive anything back for this (except a tax deduction) and a positive experience as a cheerful giver.
Thoughts?
Also would anyone be up for this?
Obviously, this could be done as an individual alone, but I think that if we have a chance to design this fundraiser to 'increase the impact of the deal' where it makes a positive impact for BiblePay, and also for the giver then it is better to do this as a team for biblepay than alone.
Also, I have been reaching out to two of our vendors who offer Orphan early-termination insurance, meaning that they both guarantee the orphan will not be dropped from the benefits program if we pick them up and drop them (they will be subsidized by the insurance they carry or moved to another beneficiary). Both Compassion.com and CAMEROON ONE offer this.
As far as a personal tax deduction, I believe it will be possible to receive the deduction if you give to Cameroon One. As they will allow the check to be sent to them, and the orphan to be in the BiblePay account. Compassion on the other hand does not accept checks from third parties therefore the tax deduction is not possible with them.
So here is what I am thinking as a rough idea:
I ask the community for an idea of how many orphans our whales are willing to sponsor each.
I agree to match an equal amount of BBP/USD to sponsor an equal amount of orphans (IE I match the whales commitments).
BiblePay sponsors an equal amount of orphans out of that monthly superblock also.
We then increase our orphan count by 1/6th of that number (IE we adhere to our 6 month buffer). After BiblePay can no longer afford to pay, we scale back.
So an example looks like this:
Whales 1-5 decide to sponsor 40 orphans ($1600).
Rob matches this number (40) @ $1600.
The money raised goes directly to Cameroon One and Compassion (and those that pay cameroon one receive a tax deduction receipt).
We enter a proposal for BiblePay for $1600 that month also (benefiting 40 orphans).
With this combined action, we receive total funds to sponsor 120 children / 6 months = 20 new orphans.
That same month, we sponsor N from Cameroon and Y from Compassion (depending on how many went with Cameroon).
BiblePay assumes liability for the children at that point going forward.
Note that the whales do not receive anything back for this (except a tax deduction) and a positive experience as a cheerful giver.
Thoughts?
Also would anyone be up for this?
95
Archived Proposals / Compassion April 2019 Recurring sponsorships
« on: April 15, 2019, 09:28:58 AM »
We sponsor 55 compassion orphans @ $2090.00 per month.
Capping @ 5MM.
Capping @ 5MM.
96
Archived Proposals / April Payroll
« on: April 15, 2019, 09:25:17 AM »Commits on Dec 29, 2018
1.1.7.4-Leisure Upgrade …
@biblepay
biblepay committed on Dec 29, 2018
Merge branch 'master' of https://github.com/biblepay/biblepay …
@biblepay
biblepay committed on Dec 29, 2018
1.1.7.3b-Leisure Upgrade …
@biblepay
biblepay committed on Dec 29, 2018
bump version to 1.1.7.3 (leisure for mainnet&testnet)
Merge branch 'develop' (issues and PPA scripts & doc) …
Issue #55 hide boincmd shell windows in Win32/64
Restore dash xpm files to allow Licht's ubuntu PPAs to build without … …
Issue #62 some failure routes in SignStake might leave wallet unlocked
1.1.7.3-Leisure Upgrade …
@biblepay
biblepay committed on Dec 29, 2018
Commits on Dec 25, 2018
1.1.7.2c-Leisure Upgrade …
@biblepay
biblepay committed on Dec 25, 2018
Commits on Dec 24, 2018
1.1.7.2b-Leisure Upgrade …
@biblepay
biblepay committed on Dec 24, 2018
ommits on Dec 23, 2018
1.1.7.2-Leisure Upgrade (Mandatory for TestNet) …
@biblepay
biblepay committed on Dec 23, 2018
Commits on Dec 21, 2018
1.1.7.1-Leisure Upgrade …
@biblepay
biblepay committed on Dec 21, 2018
Commits on Dec 20, 2018
1.1.7.0b-Leisure Upgrade …
@biblepay
biblepay committed on Dec 20, 2018
Commits on Dec 19, 2018
1.1.7.0-Leisure Upgrade …
@biblepay
biblepay committed on Dec 19, 2018
1.1.6.9b-Leisure Upgrade …
@biblepay
biblepay committed on Dec 19, 2018
1.1.6.9 - Leisure Upgrade (Mandatory for TestNet) …
@biblepay
biblepay committed on Dec 19, 2018
Commits on Dec 17, 2018
1.1.6.8-Leisure Upgrade …
@biblepay
biblepay committed on Dec 17, 2018
Commits on Dec 16, 2018
1.1.6.7-Leisure Upgrade (Mandatory for TestNet) …
@biblepay
biblepay committed on Dec 16, 2018
4
Commits on Dec 13, 2018
1.1.6.6-Leisure Upgrade (Mandatory for TestNet) …
@biblepay
biblepay committed on Dec 13, 2018
1.1.6.5b-Leisure Upgrade …
@biblepay
biblepay committed on Dec 13, 2018
1.1.6.5-Leisure Upgrade (Mandatory for TestNet) …
@biblepay
biblepay committed on Dec 13, 2018
Commits on Dec 12, 2018
1.1.6.4g-Leisure Upgrade (TestNet) …
@biblepay
biblepay committed on Dec 12, 2018
1.1.6.4f-Leisure Upgrade …
@biblepay
biblepay committed on Dec 12, 2018
1.1.6.4e-Leisure Upgrade …
@biblepay
biblepay committed on Dec 12, 2018
1.1.6.4d-Leisure Upgrade (Mandatory for TestNet) …
@biblepay
biblepay committed on Dec 12, 2018
@biblepay
biblepay committed on Dec 12, 2018
1.1.6.4c-Leisure Upgrade (Mandatory for TestNet) …
@biblepay
biblepay committed on Dec 12, 2018
1.1.6.4c-Leisure Upgrade (Mandatory for TestNet)
Commits on Dec 11, 2018
1.1.6.4b-Leisure Upgrade (Mandatory for TestNet) …
@biblepay
biblepay committed on Dec 11, 2018
1.1.6.4-Leisure (Mandatory for TestNet) …
@biblepay
biblepay committed on Dec 11, 2018
Commits on Dec 8, 2018
1.1.6.3-Leisure Upgrade (Mandatory for TestNet) …
@biblepay
biblepay committed on Dec 8, 2018
1.1.6.2h-Leisure Upgrade(Testnet only) …
@biblepay
biblepay committed on Dec 8, 2018
Commits on Dec 7, 2018
1.1.6.2g-Leisure Upgrade (TestNet) …
@biblepay
biblepay committed on Dec 7, 2018
2
1.1.6.2f-Leisure Upgrade (TestNet only) …
@biblepay
biblepay committed on Dec 7, 2018
1.1.6.2e-Leisure(Testnet Only) …
@biblepay
biblepay committed on Dec 7, 2018
1.1.6.2d-Leisure (TestNet only) …
@biblepay
biblepay committed on Dec 7, 2018
Commits on Dec 6, 2018
1.1.6.2c-Leisure (testnet) …
@biblepay
biblepay committed on Dec 6, 2018
1.1.6.2b-Leisure (Testnet only) …
@biblepay
biblepay committed on Dec 6, 2018
1.1.6.2-Leisure Upgrade (Testnet only) …
@biblepay
biblepay committed on Dec 6, 2018
> 12MM, capping at 3MM
97
Archived Proposals / Side By Side Women of Uganda
« on: April 06, 2019, 10:34:22 AM »
First a little history.
We sponsored 10 orphans through BLOOM up til Dec 31, 2018.
During the beginning of the year we technically could not afford to continue to sponsor the full quantity, so we intended to scale back to at least 5 or lower this year.
We received a message from Sarah at Side by Side (this is Blooms vendor) that 'payment has been cancelled' as of 2019 (another words the children are at risk of being dropped from the boarding school) and she asked if we could do anything directly (IE would we like to step in and sponsor any of these children).
I asked which 4 would need us the most? She listed:
Favor
https://biblepaysponsorkids.tumblr.com/post/171309417994
Praise
https://biblepaysponsorkids.tumblr.com/post/171309472084
Isaac
https://biblepaysponsorkids.tumblr.com/post/171309538169
Musigale
https://biblepaysponsorkids.tumblr.com/post/171309583169
TheSnat and I started to train her on how to liquidate crypto, but she has not successfully finished that course (she is working with him now).
In the mean time I volunteered to step in and pay for 90 days, one-time to continue the children so that they do not have to leave the boarding school.
Note that this particular arrangement is $80 per child per month because they receive not only the normal meals and school, but also boarding.
I am requesting $320 * 3 months = $960.00 or 3,720,930bbp.
Receipt - sending wire now:
http://pool.biblepay.org/san/Expenses/sidebyside.pdf
We sponsored 10 orphans through BLOOM up til Dec 31, 2018.
During the beginning of the year we technically could not afford to continue to sponsor the full quantity, so we intended to scale back to at least 5 or lower this year.
We received a message from Sarah at Side by Side (this is Blooms vendor) that 'payment has been cancelled' as of 2019 (another words the children are at risk of being dropped from the boarding school) and she asked if we could do anything directly (IE would we like to step in and sponsor any of these children).
I asked which 4 would need us the most? She listed:
Favor
https://biblepaysponsorkids.tumblr.com/post/171309417994
Praise
https://biblepaysponsorkids.tumblr.com/post/171309472084
Isaac
https://biblepaysponsorkids.tumblr.com/post/171309538169
Musigale
https://biblepaysponsorkids.tumblr.com/post/171309583169
TheSnat and I started to train her on how to liquidate crypto, but she has not successfully finished that course (she is working with him now).
In the mean time I volunteered to step in and pay for 90 days, one-time to continue the children so that they do not have to leave the boarding school.
Note that this particular arrangement is $80 per child per month because they receive not only the normal meals and school, but also boarding.
I am requesting $320 * 3 months = $960.00 or 3,720,930bbp.
Receipt - sending wire now:
http://pool.biblepay.org/san/Expenses/sidebyside.pdf
98
Archived Proposals / Consolidation of Sanctuaries
« on: April 05, 2019, 08:33:46 PM »
Since BiblePay is moving to Evolution in June, we have the opportunity to potentially change the Sanctuary lockup requirements from 1,550,001 to another figure.
I think this would be a good time to discuss potentially changing this lockup requirement higher in order to :
- Give our investors more ROI per Sanc
- Decrease Hosting Costs
- Increase reliability per Sanc (because user may afford a higher quality host and have more time to monitor each sanc)
The obvious downside to this is a higher barrier of entry cost for the small investor.
But, with our recent downturn in price bringing a sanctuary investment to only $400, I think this is a feasible idea.
For me as an investor, I would personally lean towards consolidating so I can spend less on hosting fees.
Analyzing the effect of wasted hosting:
We currently have about 500 sancs.
Our sanc owners are spending a very high percentage of the revenue on hosting (If hosting is $10 per month, with $20 of revenue that is 50% spent on hosting).
I believe reducing the sanc count by half will not hurt biblepay (as 250 nodes are still more than enough to service our network), and, it could be argued that 250 high quality sancs are better than 500 low quality sancs (as with low quality instant sends could get lost).
Additionally over the next 5 years, even if we move to 125 sancs, our sanc count will again increase (due to more coins being emitted and a lockup ratio average of approx 50% coins become locked into sancs).
I propose that we enter 3 sanctuary proposals floating this idea with different size lockups:
1) 3 million lockup
2) 4.5 million lockup
3) 7 million lockup
If all 3 are voted down we keep 1.55 MM.
I think this would be a good time to discuss potentially changing this lockup requirement higher in order to :
- Give our investors more ROI per Sanc
- Decrease Hosting Costs
- Increase reliability per Sanc (because user may afford a higher quality host and have more time to monitor each sanc)
The obvious downside to this is a higher barrier of entry cost for the small investor.
But, with our recent downturn in price bringing a sanctuary investment to only $400, I think this is a feasible idea.
For me as an investor, I would personally lean towards consolidating so I can spend less on hosting fees.
Analyzing the effect of wasted hosting:
We currently have about 500 sancs.
Our sanc owners are spending a very high percentage of the revenue on hosting (If hosting is $10 per month, with $20 of revenue that is 50% spent on hosting).
I believe reducing the sanc count by half will not hurt biblepay (as 250 nodes are still more than enough to service our network), and, it could be argued that 250 high quality sancs are better than 500 low quality sancs (as with low quality instant sends could get lost).
Additionally over the next 5 years, even if we move to 125 sancs, our sanc count will again increase (due to more coins being emitted and a lockup ratio average of approx 50% coins become locked into sancs).
I propose that we enter 3 sanctuary proposals floating this idea with different size lockups:
1) 3 million lockup
2) 4.5 million lockup
3) 7 million lockup
If all 3 are voted down we keep 1.55 MM.
99
TestNet Discussion Archive / TestNet - BiblePay-Evolution & GSCs (Generic Smart Contracts)
« on: March 24, 2019, 01:17:09 PM »
EVOLUTION
Currently testing Dash 0.14 features in BiblePay v1.4.6.3+
Testnet Download Links:
Windows v.1.4.6.3+:
https://biblepay.org/biblepayevo32develop.exe
Linux PC 32bits
Daemon: https://biblepay.org/biblepayd-evo-testnet-i686-pc-linux-gnu.tar.gz
QT: https://biblepay.org/biblepay-qt-evo-testnet-i686-pc-linux-gnu.tar.gz
Linux PC 64bits
Daemon: https://biblepay.org/biblepayd-evo--testnet-x86_64-pc-linux-gnu.tar.gz
QT: https://biblepay.org/biblepay-qt-evo-testnet-i686-pc-linux-gnu.tar.gz
Linux ARM64 daemon: https://biblepay.org/biblepayd-evo-testnet-aarch64-linux-gnu.tar.gz
Linux ARM32 daemon: https://biblepay.org/biblepayd-evo-testnet-arm-linux-gnueabihf.tar.gz
MacOS QT: https://biblepay.org/biblepaycore-evo-testnet.dmg
Mac-OS QT version here:
https://www.biblepay.org/biblepaycore-testnet.dmg
The purpose of this thread is to test BiblePay-Evolution and our new GSCs.
BiblePay-Evolution is our next release (scheduled for June 2019).
It includes all of the features that Bitcoin and Dash added to Dash over the course of 2018.
Including Segwit, Security updates, Lightning network support, BIPS and DIPS, ChainLocks (51% attack prevention), Deterministic Masternodes, Non-financial transactions, the Depends Development Build environment, C++14 compatibility for devs, more reliable chain syncing, better chain reorganization code, more reliable Governance messages, more efficient messages, HD wallets, High definition display support, InstantSend improvements, and more.
In BIblePay, we have added ABN (Anti-BotNet) mining. This is a feature that requires miners to include an ABN transaction in each of their blocks that spends coin-age according to the network coin-age requirement (see getmininginfo).
We have also added GSCs (Generic Smart Contracts) client and server side. The GSC allows BiblePay to abstract payments away from a hard consensus to allow the business logic rules to be malleable and configured so that they do not break consensus rules. This results in a more reliable prod environment.
Before testing, please read about our GSC's here:
https://wiki.biblepay.org/Generic_Smart_Contracts
To Download BiblePay-Evolution, look for v1.4.0.1+ for windows on this link (at first, we will stay with 32 bit builds until we get close to Prod):
https://biblepay.org/biblepaycore-1.4.0-win32-setup.exe
MIP is working on building linux and MAC builds. If necessary I will be able to release a link for Ubuntu64 builds/linux also.
To self compile Evo:
https://github.com/biblepay/biblepay-evolution/blob/master/BuildBiblePay.txt
Let us start by testing standard core functionality in testnet.
Launching the client:
Create a biblepaytest.conf file with the following contents:
testnet=1
debug=1
Place the file in ~/.biblepayevolution
Start testnet by typing:
./biblepay-qt -conf=biblepaytest.conf
(Note the blocks and chainstate will sync into the ./biblepayevolution/testnet3 folder.
NOTE: We are keeping BiblePay's blocks, wallet, and chainstate in its own dedicated folder until the end of the test cycle at which time we determine if it is safe to change our pointer back to legacy biblepay files (as Evolutions blocks support a new file format, compressed, and Evo's wallet format has also been upgraded), so it is safer for us to keep these separate for now.
NOTE: This version will also work side-by-side our production nodes, it will sync blocks, send and receive coins, however it will not peer with legacy Sanctuaries (as their protocol is too old). We will need to test creation and usage of Sancs in Prod in Evo, and upgrade all legacy Sancs with a mandatory.
Getting started with Evolution:
https://wiki.biblepay.org/Getting_Started_with_Evolution
GSC's:
https://wiki.biblepay.org/Generic_Smart_Contracts
Healing Campaign:
https://wiki.biblepay.org/BiblePay_Healing_Campaign
Street Healing:
https://wiki.biblepay.org/Street_Healing
Spiritual Warfare:
https://wiki.biblepay.org/Spiritual-Warfare-I
How to upgrade a legacy Sanc:
https://forum.biblepay.org/index.php?topic=391.msg5968#msg5968
How to create a deterministic sanc from scratch:
https://docs.dash.org/en/stable/masternodes/dip3-upgrade.html
** Low hassle Syncing from Zero **
EDIT: NOTE: Please do not use low hassle syncing in testnet after September 22nd 2019 - as we have reset the chain to block 0, please disregard the following lines.
(Keeping this here so we can port this to prod during the next release).
As our blockchain gets bigger it will be useful for us to release utilities to allow one click syncing from zero.
This first version is only for testnet and linux. Later, I will extend this to windows and prod.
I will check this into github later, but for now, let me give manual instructions to use the script:
From your linux box:
cd ~/biblepay-evolution
(This is where your source starts, ie /src is one folder down)
wget biblepay.org/syncblocks_testnet.sh
chmod 777 syncblocks_testnet.sh
Now to get in sync for TestNet only, the script automatically deletes just the data files (dont worry, it wont delete anything else), then it pulls down the snapshot of the blocks gzipped and unzips them into the correct places (including the llmq and all necessary governance files), then its up to you re-launch the wallet. The script does close biblepay as long as your machine supports pkill.
To sync from 0 type:
./syncblocks_testnet.sh
EDIT:
I just created a windows version and tested it on windows 7 and it works. Will check-in during the next Develop release.
Currently testing Dash 0.14 features in BiblePay v1.4.6.3+
Testnet Download Links:
Windows v.1.4.6.3+:
https://biblepay.org/biblepayevo32develop.exe
Linux PC 32bits
Daemon: https://biblepay.org/biblepayd-evo-testnet-i686-pc-linux-gnu.tar.gz
QT: https://biblepay.org/biblepay-qt-evo-testnet-i686-pc-linux-gnu.tar.gz
Linux PC 64bits
Daemon: https://biblepay.org/biblepayd-evo--testnet-x86_64-pc-linux-gnu.tar.gz
QT: https://biblepay.org/biblepay-qt-evo-testnet-i686-pc-linux-gnu.tar.gz
Linux ARM64 daemon: https://biblepay.org/biblepayd-evo-testnet-aarch64-linux-gnu.tar.gz
Linux ARM32 daemon: https://biblepay.org/biblepayd-evo-testnet-arm-linux-gnueabihf.tar.gz
MacOS QT: https://biblepay.org/biblepaycore-evo-testnet.dmg
Mac-OS QT version here:
https://www.biblepay.org/biblepaycore-testnet.dmg
The purpose of this thread is to test BiblePay-Evolution and our new GSCs.
BiblePay-Evolution is our next release (scheduled for June 2019).
It includes all of the features that Bitcoin and Dash added to Dash over the course of 2018.
Including Segwit, Security updates, Lightning network support, BIPS and DIPS, ChainLocks (51% attack prevention), Deterministic Masternodes, Non-financial transactions, the Depends Development Build environment, C++14 compatibility for devs, more reliable chain syncing, better chain reorganization code, more reliable Governance messages, more efficient messages, HD wallets, High definition display support, InstantSend improvements, and more.
In BIblePay, we have added ABN (Anti-BotNet) mining. This is a feature that requires miners to include an ABN transaction in each of their blocks that spends coin-age according to the network coin-age requirement (see getmininginfo).
We have also added GSCs (Generic Smart Contracts) client and server side. The GSC allows BiblePay to abstract payments away from a hard consensus to allow the business logic rules to be malleable and configured so that they do not break consensus rules. This results in a more reliable prod environment.
Before testing, please read about our GSC's here:
https://wiki.biblepay.org/Generic_Smart_Contracts
To Download BiblePay-Evolution, look for v1.4.0.1+ for windows on this link (at first, we will stay with 32 bit builds until we get close to Prod):
https://biblepay.org/biblepaycore-1.4.0-win32-setup.exe
MIP is working on building linux and MAC builds. If necessary I will be able to release a link for Ubuntu64 builds/linux also.
To self compile Evo:
https://github.com/biblepay/biblepay-evolution/blob/master/BuildBiblePay.txt
Let us start by testing standard core functionality in testnet.
Launching the client:
Create a biblepaytest.conf file with the following contents:
testnet=1
debug=1
Place the file in ~/.biblepayevolution
Start testnet by typing:
./biblepay-qt -conf=biblepaytest.conf
(Note the blocks and chainstate will sync into the ./biblepayevolution/testnet3 folder.
NOTE: We are keeping BiblePay's blocks, wallet, and chainstate in its own dedicated folder until the end of the test cycle at which time we determine if it is safe to change our pointer back to legacy biblepay files (as Evolutions blocks support a new file format, compressed, and Evo's wallet format has also been upgraded), so it is safer for us to keep these separate for now.
NOTE: This version will also work side-by-side our production nodes, it will sync blocks, send and receive coins, however it will not peer with legacy Sanctuaries (as their protocol is too old). We will need to test creation and usage of Sancs in Prod in Evo, and upgrade all legacy Sancs with a mandatory.
Getting started with Evolution:
https://wiki.biblepay.org/Getting_Started_with_Evolution
GSC's:
https://wiki.biblepay.org/Generic_Smart_Contracts
Healing Campaign:
https://wiki.biblepay.org/BiblePay_Healing_Campaign
Street Healing:
https://wiki.biblepay.org/Street_Healing
Spiritual Warfare:
https://wiki.biblepay.org/Spiritual-Warfare-I
How to upgrade a legacy Sanc:
https://forum.biblepay.org/index.php?topic=391.msg5968#msg5968
How to create a deterministic sanc from scratch:
https://docs.dash.org/en/stable/masternodes/dip3-upgrade.html
** Low hassle Syncing from Zero **
EDIT: NOTE: Please do not use low hassle syncing in testnet after September 22nd 2019 - as we have reset the chain to block 0, please disregard the following lines.
(Keeping this here so we can port this to prod during the next release).
As our blockchain gets bigger it will be useful for us to release utilities to allow one click syncing from zero.
This first version is only for testnet and linux. Later, I will extend this to windows and prod.
I will check this into github later, but for now, let me give manual instructions to use the script:
From your linux box:
cd ~/biblepay-evolution
(This is where your source starts, ie /src is one folder down)
wget biblepay.org/syncblocks_testnet.sh
chmod 777 syncblocks_testnet.sh
Now to get in sync for TestNet only, the script automatically deletes just the data files (dont worry, it wont delete anything else), then it pulls down the snapshot of the blocks gzipped and unzips them into the correct places (including the llmq and all necessary governance files), then its up to you re-launch the wallet. The script does close biblepay as long as your machine supports pkill.
To sync from 0 type:
./syncblocks_testnet.sh
EDIT:
I just created a windows version and tested it on windows 7 and it works. Will check-in during the next Develop release.
100
Archived Proposals / Compassion March 2019 Recurring Sponsorships
« on: March 22, 2019, 11:07:00 AM »
Our recurring charge is approx $2090, or 8.931MM, capping at 7MM.
101
Archived Proposals / March 2019 Payroll
« on: March 22, 2019, 10:58:53 AM »
I'm posting my commits from November 2018, because back when we started BiblePay, we didn't have a governance system until December 2017 (that is why these invoices are 4 months old) (not because our price dropped, or because we are trying to back-invoice), these have been consistently behind since the beginning.
Commits on Nov 21, 2018
Merge branch 'master' of https://github.com/biblepay/biblepay
@biblepay
biblepay committed on Nov 21, 2018
1.1.6.1 - Leisure Upgrade …
@biblepay
biblepay committed on Nov 21, 2018
Commits on Nov 19, 2018
PPA script and doc
1.1.6.0-Leisure …
@biblepay
biblepay committed on Nov 16, 2018
Merge branch 'master' of https://github.com/biblepay/biblepay
@biblepay
biblepay committed on Nov 16, 2018
1.1.5.9f-Leisure Upgrade …
@biblepay
biblepay committed on Nov 16, 2018
Merge pull request #45 from thesnat21/Add_Spork_Outputs …
Commits on Nov 14, 2018
Better detection for BOINC client and error messages per OS
disable boost::process ShellCommand temporarily for non MacOS until w… …
Commits on Nov 11, 2018
boinccmd call for MacOS (https://forum.biblepay.org/index.php?topic=2… …
Commits on Nov 2, 2018
I'm requesting 80 hrs * 40 = 3200 = 13.2MM bbp, capping @ 3.5 MM
Commits on Nov 21, 2018
Merge branch 'master' of https://github.com/biblepay/biblepay
@biblepay
biblepay committed on Nov 21, 2018
1.1.6.1 - Leisure Upgrade …
@biblepay
biblepay committed on Nov 21, 2018
Commits on Nov 19, 2018
PPA script and doc
1.1.6.0-Leisure …
@biblepay
biblepay committed on Nov 16, 2018
Merge branch 'master' of https://github.com/biblepay/biblepay
@biblepay
biblepay committed on Nov 16, 2018
1.1.5.9f-Leisure Upgrade …
@biblepay
biblepay committed on Nov 16, 2018
Merge pull request #45 from thesnat21/Add_Spork_Outputs …
Commits on Nov 14, 2018
Better detection for BOINC client and error messages per OS
disable boost::process ShellCommand temporarily for non MacOS until w… …
Commits on Nov 11, 2018
boinccmd call for MacOS (https://forum.biblepay.org/index.php?topic=2… …
Commits on Nov 2, 2018
I'm requesting 80 hrs * 40 = 3200 = 13.2MM bbp, capping @ 3.5 MM
102
Archived Proposals / The Future of PODC - Proof of Distributed Computing
« on: February 28, 2019, 11:52:58 AM »
DECIDING THE FUTURE OF PODC - PROOF OF DISTRIBUTED COMPUTING
Feb 28th, 2019
My what a ride its been in 2018. (If we only knew everything that we know now, before the beginning of 2018, we would all be a little further ahead in life) - but for me - drawing closer to Jesus is the greatest achievement, and should never be traded for anything.
Going into 2018, I thought I was already experienced, but 2018 redefined that 'assumption' in many ways. We had lots of things happen in our forums. We had the huge HODL rise and crash. I think while we were at our peak of 329 monthly orphans, we also took a lot of credit for this rise as if we - as a community - succeeded at something. Another words, we should have been monitoring for our own pride and improving - but we let ourselves fall with the HODL fall. Be very wary of taking credit for achievements -- I believe we were primarily influenced from external forces. The cryptocurrency market was clearly influenced by Bitcoin and Dashes rise (and fall).
I personally had strong opinions of long held beliefs in certain areas only to be tested, and I've changed my opinion about certain things. We had our sessions with our focus group (our internal advisors) and our external advisors (an SEC attorney, Manna, outwest advisors, DAHF, etc) and learned that we should be a utility, with a known revenue stream. That going with DAHF would have pulled us in an anti-God direction. And that we should add infrastructure to invite a Christian base to use the gospel features.
I'm only saying all of this because I want people to realize that many factors influence the decision of a good algorithm for BiblePay. It's not that we are being hot and cold, it's that this is a complicated environment, and I personally want to make a long lasting decision that satisfies all of the facets to the highest degree.
We are trying to decide if we should retire PODC or keep it as an algorithm within Biblepay-core.
The impetus for removing it is that a lot of us feel that our user-base has stagnated because PODC is too hard to understand and set up.
Thefore, it prevents us from sending the wallet to a brand new user - and allowing them to figure out on their own how to set up mining, receive rewards and tell their friends about BBP (free advertising and growth).
The problem with keeping both algorithms is it requires constant maintenace from the developers to focus on more than one. The other problem is splitting rewards by 96% and 4% does not give POG the chance to grow. So, the question is, should we completely retire PODC, and give the budget over to POG, so that POG can potentially grow our userbase automatically?
It could also be potentially floated to split the algorithms 50-50, allowing them to compete. However, the issue with this is then our IT department still must support PODC and all of its related dependencies and infrastructure. And, does a 50% PODC environment help biblepay more than a 100% POG environment?
That is what we will be discussing here.
Let me name off some of the facets in a mining algorithm:
IT Development Hours
IT Maintenance Hours
Coolness factor
Risk of a constantly supply of work units
User attrition/augmentation levels, Practicality, User Acceptance, Ease of Use, Community Growth/Price appreciation/Total orphan benefit
Algorithm Extensibility/Fragility
Hard emission reconciliation/Oracles, Whale Approval
Total infrastructure size and maintenance (3rd party credit sites, credit network, debug tool sites, pools)
Greed-Arms Race-Rat Race Levels
Jesus' (Christian Growth) levels/Christian Attraction/Christian Future
Blockchain Security
To start to compare the PODC algorithm to POG, let me first attempt to name some of the pros and cons of PODC:
NOTE! The following views are *my opinion* as founder; if you disagree please have a civil conversation below, and vote appropriately.
Pros with PODC:
IT/Development: The Creation of PODC is already coded
Coolness: The Rosetta cancer mining program is 'cool' and gives us a good image as in doing positive work for humanity, the highly technical users are drawn to 'try' podc as a challenge
Extensibility: The algorithm is modular (in that it works outside of biblepay and uses a sanctuary consensus), and extensible (in that business logic changes can be made at the sanc level without requiring a mandatory)
Price Support: PODC has the 20bbp-per-rac rule meaning it "may or may not" cause price appreciation (I vote neutral on this as we can't tell at this point if this is good or bad for our price, since we appear to be stagnating).
Cons with PODC:
User Acceptance: The algorithm requires a dictionary of terminology to understand, so it appears to be complicated to learn by newbies, it appears to be complicated to be activated and maintained (without knowing the inner workings under the hood to understand how to keep it purring)
Dev Maintenance: Development hours for Enhancing podc are still not complete, the algorithm certainly needs improved in the area of ease of use, the maintenance hours involved in maintaining PODC from an IT standpoint are relatively high
Fragility: Fragility is high, the risk of the contract breaking or changing is high, and the BOINC/Rosetta/WCG interface risk is high
Work-unit-risk: The risk of work-units running out is medium to high
User attrition levels: User levels appear to be low and stagnating (based on our sideways to shrinking podc diff level and user count), podc appears to attract richer users with many horizontal computers (in contrast to average users with a low pc count)-and this appears to stagnate growth as the rich users take a high percentage of rewards away from the small users. The small user base appears to have stagnated our price into a range of 7 satoshi (due to the average miner being reluctant to sell below the electricity cost of PODC). (I feel BBP has a much bigger potential in many other ways).
Infrastructure Size and maintenance: The total infrastructure size is High (due to needing 3rd party tools for debugging and for credit reporting), and third party sites like pools and web support sites need maintained.
Greed-Rat-Race-Arms Race Level: The Greed/Rat-Race level appears to be very high (as each user wants to achieve higher RAC than others) and this appears to create an environment in BBP where higher results are more important than talking about the gospel (Ive posted many snippets to links about Jesus in the middle of our forum, and actually was screamed at by people saying I was spamming, but yet I dont recall anyone starting a real conversation - other than a couple people who just disagreed about the Jews a year ago).
The people we are attracting to the community for cancer research seem to be more scientific and less Theological (this is entirely an assumption and I dont mean to offend anyone - I actually want the atheists to come, but they dont appear to be coming to learn about Jesus from PODC), and I realize this is a hard requirement, so I simplify this down to : how can we attract a LOT of new users that turn to Christians that stick around.
Blockchain Security: We have less hashpower being directed at POBH and more to PODC (because financially PODC pays 96% of the reward) so this results in less total network security with more machine power being used for RAC.
Oracle/Whale Approval: Whales may be reluctant to jump in as a BiblePay investor if emissions are not fully reconcilable in a hard way on-chain (when the whale takes into account the entire subject for coinbase-reconciliation).
Pros with POG:
IT/Creation: POG is coded, 99% of the POG maintenance (est) is already completed
IT/Maintenance: POG is low maintenance
Work-Unit-Risk: POG does not have a work-unit limit
User attrition/growth: POG has the capacity to attract *more users per consumed electricity KWH than PODC* because it is 80% greener than PODC and in addition it rewards users for holding distinct coins (meaning that a reconciled POG user daily reward points to One head, not many machines) therefore I conclude POG equals more HEADCOUNT than PODC, This theoretically means BiblePay expands its participation level, this results in community growth/help with tasks/price appreciation/more orphans, POG is very easy to setup - it is almost turnkey.
Fragility: The algorithm is not fragile
Reconciliation/Trust/WhaleApproval: The payment emissions are hard and reconcilable, there is no oracle / trust issue, there is no tampering issue, POG would theoretically be whale approved.
Infrastructure: POG reduces total infrastructure down to an in-wallet novel pool and removes the need for 3rd party credit sites, pools, and debug tools.
Greed-arms-race-rat-race: The rat-race and greed level appears to be very low (as people will be Giving to the foundation to receive a reward and hashing on single machines per head) and only out of personal generosity running multiple hashing machines.
Christian Growth: The total headcount appears to be aligned with increasing the attraction of Christian community members
Blockchain Security: Security is increased due to having an increasing reward (1 mil per day towards pog) means a 10* userbase size increase, meaning a 10* POW security increase. POG scales well to thousands of users.
Cons with POG:
Coolness factor: POG is much more "simple" than PODC (IE we aren't solving humanity's most complex problems) so we lose the "cool" factor of cancer-mining.
Extensibility: POG can't allow us (currently) to change its rules without a mandatory (extensibility).
Feb 28th, 2019
My what a ride its been in 2018. (If we only knew everything that we know now, before the beginning of 2018, we would all be a little further ahead in life) - but for me - drawing closer to Jesus is the greatest achievement, and should never be traded for anything.
Going into 2018, I thought I was already experienced, but 2018 redefined that 'assumption' in many ways. We had lots of things happen in our forums. We had the huge HODL rise and crash. I think while we were at our peak of 329 monthly orphans, we also took a lot of credit for this rise as if we - as a community - succeeded at something. Another words, we should have been monitoring for our own pride and improving - but we let ourselves fall with the HODL fall. Be very wary of taking credit for achievements -- I believe we were primarily influenced from external forces. The cryptocurrency market was clearly influenced by Bitcoin and Dashes rise (and fall).
I personally had strong opinions of long held beliefs in certain areas only to be tested, and I've changed my opinion about certain things. We had our sessions with our focus group (our internal advisors) and our external advisors (an SEC attorney, Manna, outwest advisors, DAHF, etc) and learned that we should be a utility, with a known revenue stream. That going with DAHF would have pulled us in an anti-God direction. And that we should add infrastructure to invite a Christian base to use the gospel features.
I'm only saying all of this because I want people to realize that many factors influence the decision of a good algorithm for BiblePay. It's not that we are being hot and cold, it's that this is a complicated environment, and I personally want to make a long lasting decision that satisfies all of the facets to the highest degree.
We are trying to decide if we should retire PODC or keep it as an algorithm within Biblepay-core.
The impetus for removing it is that a lot of us feel that our user-base has stagnated because PODC is too hard to understand and set up.
Thefore, it prevents us from sending the wallet to a brand new user - and allowing them to figure out on their own how to set up mining, receive rewards and tell their friends about BBP (free advertising and growth).
The problem with keeping both algorithms is it requires constant maintenace from the developers to focus on more than one. The other problem is splitting rewards by 96% and 4% does not give POG the chance to grow. So, the question is, should we completely retire PODC, and give the budget over to POG, so that POG can potentially grow our userbase automatically?
It could also be potentially floated to split the algorithms 50-50, allowing them to compete. However, the issue with this is then our IT department still must support PODC and all of its related dependencies and infrastructure. And, does a 50% PODC environment help biblepay more than a 100% POG environment?
That is what we will be discussing here.
Let me name off some of the facets in a mining algorithm:
IT Development Hours
IT Maintenance Hours
Coolness factor
Risk of a constantly supply of work units
User attrition/augmentation levels, Practicality, User Acceptance, Ease of Use, Community Growth/Price appreciation/Total orphan benefit
Algorithm Extensibility/Fragility
Hard emission reconciliation/Oracles, Whale Approval
Total infrastructure size and maintenance (3rd party credit sites, credit network, debug tool sites, pools)
Greed-Arms Race-Rat Race Levels
Jesus' (Christian Growth) levels/Christian Attraction/Christian Future
Blockchain Security
To start to compare the PODC algorithm to POG, let me first attempt to name some of the pros and cons of PODC:
NOTE! The following views are *my opinion* as founder; if you disagree please have a civil conversation below, and vote appropriately.
Pros with PODC:
IT/Development: The Creation of PODC is already coded
Coolness: The Rosetta cancer mining program is 'cool' and gives us a good image as in doing positive work for humanity, the highly technical users are drawn to 'try' podc as a challenge
Extensibility: The algorithm is modular (in that it works outside of biblepay and uses a sanctuary consensus), and extensible (in that business logic changes can be made at the sanc level without requiring a mandatory)
Price Support: PODC has the 20bbp-per-rac rule meaning it "may or may not" cause price appreciation (I vote neutral on this as we can't tell at this point if this is good or bad for our price, since we appear to be stagnating).
Cons with PODC:
User Acceptance: The algorithm requires a dictionary of terminology to understand, so it appears to be complicated to learn by newbies, it appears to be complicated to be activated and maintained (without knowing the inner workings under the hood to understand how to keep it purring)
Dev Maintenance: Development hours for Enhancing podc are still not complete, the algorithm certainly needs improved in the area of ease of use, the maintenance hours involved in maintaining PODC from an IT standpoint are relatively high
Fragility: Fragility is high, the risk of the contract breaking or changing is high, and the BOINC/Rosetta/WCG interface risk is high
Work-unit-risk: The risk of work-units running out is medium to high
User attrition levels: User levels appear to be low and stagnating (based on our sideways to shrinking podc diff level and user count), podc appears to attract richer users with many horizontal computers (in contrast to average users with a low pc count)-and this appears to stagnate growth as the rich users take a high percentage of rewards away from the small users. The small user base appears to have stagnated our price into a range of 7 satoshi (due to the average miner being reluctant to sell below the electricity cost of PODC). (I feel BBP has a much bigger potential in many other ways).
Infrastructure Size and maintenance: The total infrastructure size is High (due to needing 3rd party tools for debugging and for credit reporting), and third party sites like pools and web support sites need maintained.
Greed-Rat-Race-Arms Race Level: The Greed/Rat-Race level appears to be very high (as each user wants to achieve higher RAC than others) and this appears to create an environment in BBP where higher results are more important than talking about the gospel (Ive posted many snippets to links about Jesus in the middle of our forum, and actually was screamed at by people saying I was spamming, but yet I dont recall anyone starting a real conversation - other than a couple people who just disagreed about the Jews a year ago).
The people we are attracting to the community for cancer research seem to be more scientific and less Theological (this is entirely an assumption and I dont mean to offend anyone - I actually want the atheists to come, but they dont appear to be coming to learn about Jesus from PODC), and I realize this is a hard requirement, so I simplify this down to : how can we attract a LOT of new users that turn to Christians that stick around.
Blockchain Security: We have less hashpower being directed at POBH and more to PODC (because financially PODC pays 96% of the reward) so this results in less total network security with more machine power being used for RAC.
Oracle/Whale Approval: Whales may be reluctant to jump in as a BiblePay investor if emissions are not fully reconcilable in a hard way on-chain (when the whale takes into account the entire subject for coinbase-reconciliation).
Pros with POG:
IT/Creation: POG is coded, 99% of the POG maintenance (est) is already completed
IT/Maintenance: POG is low maintenance
Work-Unit-Risk: POG does not have a work-unit limit
User attrition/growth: POG has the capacity to attract *more users per consumed electricity KWH than PODC* because it is 80% greener than PODC and in addition it rewards users for holding distinct coins (meaning that a reconciled POG user daily reward points to One head, not many machines) therefore I conclude POG equals more HEADCOUNT than PODC, This theoretically means BiblePay expands its participation level, this results in community growth/help with tasks/price appreciation/more orphans, POG is very easy to setup - it is almost turnkey.
Fragility: The algorithm is not fragile
Reconciliation/Trust/WhaleApproval: The payment emissions are hard and reconcilable, there is no oracle / trust issue, there is no tampering issue, POG would theoretically be whale approved.
Infrastructure: POG reduces total infrastructure down to an in-wallet novel pool and removes the need for 3rd party credit sites, pools, and debug tools.
Greed-arms-race-rat-race: The rat-race and greed level appears to be very low (as people will be Giving to the foundation to receive a reward and hashing on single machines per head) and only out of personal generosity running multiple hashing machines.
Christian Growth: The total headcount appears to be aligned with increasing the attraction of Christian community members
Blockchain Security: Security is increased due to having an increasing reward (1 mil per day towards pog) means a 10* userbase size increase, meaning a 10* POW security increase. POG scales well to thousands of users.
Cons with POG:
Coolness factor: POG is much more "simple" than PODC (IE we aren't solving humanity's most complex problems) so we lose the "cool" factor of cancer-mining.
Extensibility: POG can't allow us (currently) to change its rules without a mandatory (extensibility).
103
Archived Proposals / Cameroon One - Installment 2
« on: February 23, 2019, 05:58:03 PM »
We only rose $492.55 last month due to our low price, so we are asking for 2 mil more for Todd at Cameroon One.
Note: Todds colleague Hillary will handle the liquidation, thanks Hillary!
Note: Todds colleague Hillary will handle the liquidation, thanks Hillary!
104
Archived Proposals / Compassion Feb 2019 recurring orphan sponsorships
« on: February 20, 2019, 12:27:59 PM »
To maintain our 102 orphan sponsorships:
?3876/.000242
16,016,528.9256198
Capping at 6 mil.
?3876/.000242
16,016,528.9256198
Capping at 6 mil.
105
Archived Proposals / Feb Payroll
« on: February 20, 2019, 12:22:09 PM »
Commits on Oct 26, 2018
Merge pull request #48 from thesnat21/Update_Default_Theme …
@biblepay
biblepay committed on Oct 26, 2018
Commits on Oct 17, 2018
1.1.5.9c-No-Op …
@biblepay
biblepay committed on Oct 17, 2018
Commits on Oct 16, 2018
1.1.5.9b-No-Op …
@biblepay
biblepay committed on Oct 16, 2018
Commits on Oct 7, 2018
1.1.5.9-Leisure Upgrade …
@biblepay
biblepay committed on Oct 7, 2018
Commits on Oct 6, 2018
1.1.5.8-Leisure Upgrade …
@biblepay
biblepay committed on Oct 6, 2018
Commits on Oct 3, 2018
1.1.5.7d-No-Op …
@biblepay
biblepay committed on Oct 3, 2018
Commits on Oct 2, 2018
1.1.5.7c-No-op …
@biblepay
biblepay committed on Oct 2, 2018
Commits on Oct 1, 2018
1.1.5.7b-Leisure Upgrade …
@biblepay
biblepay committed on Oct 1, 2018
1.1.5.7-Mandatory Upgrade (at block 77000) …
@biblepay
biblepay committed on Oct 1, 2018
Commits on Oct 30, 2018
1.1.5.9e-Leisure Upgrade …
@biblepay
biblepay committed on Oct 30, 2018
1.1.5.9d - Leisure …
@biblepay
biblepay committed on Oct 30, 2018
Commits on Oct 26, 2018
Merge pull request #47 from thesnat21/Add_exec_helper …
@biblepay
biblepay committed on Oct 26, 2018
_____________________________________________________________________________________________________________________________________
120 hours for the month of October:
?4800/.000208
23,076,923 bbp
Capping at 3.5 Million
Merge pull request #48 from thesnat21/Update_Default_Theme …
@biblepay
biblepay committed on Oct 26, 2018
Commits on Oct 17, 2018
1.1.5.9c-No-Op …
@biblepay
biblepay committed on Oct 17, 2018
Commits on Oct 16, 2018
1.1.5.9b-No-Op …
@biblepay
biblepay committed on Oct 16, 2018
Commits on Oct 7, 2018
1.1.5.9-Leisure Upgrade …
@biblepay
biblepay committed on Oct 7, 2018
Commits on Oct 6, 2018
1.1.5.8-Leisure Upgrade …
@biblepay
biblepay committed on Oct 6, 2018
Commits on Oct 3, 2018
1.1.5.7d-No-Op …
@biblepay
biblepay committed on Oct 3, 2018
Commits on Oct 2, 2018
1.1.5.7c-No-op …
@biblepay
biblepay committed on Oct 2, 2018
Commits on Oct 1, 2018
1.1.5.7b-Leisure Upgrade …
@biblepay
biblepay committed on Oct 1, 2018
1.1.5.7-Mandatory Upgrade (at block 77000) …
@biblepay
biblepay committed on Oct 1, 2018
Commits on Oct 30, 2018
1.1.5.9e-Leisure Upgrade …
@biblepay
biblepay committed on Oct 30, 2018
1.1.5.9d - Leisure …
@biblepay
biblepay committed on Oct 30, 2018
Commits on Oct 26, 2018
Merge pull request #47 from thesnat21/Add_exec_helper …
@biblepay
biblepay committed on Oct 26, 2018
_____________________________________________________________________________________________________________________________________
120 hours for the month of October:
?4800/.000208
23,076,923 bbp
Capping at 3.5 Million